Has anyone out there succeded in getting boincview to connect to a remote host over the internet?

I have tried everything I can think of to try and achieve this, including but not limited to; mapping port 31416 on the remote firewall to the remote hosts internal IP addy and adding my local external and internal IP addies to the hosts remote_host.cfg file.

Does boincview reply via a different port, so my SPI firewall treats the packet as 'non-stateful'? Do I need to open any generic RPC ports on the remote firewall? Do I need to map a port locally? I've never had to do this for anything else (i.e. VNC, terminal services, .....), so I'm a bit baffled.

Thanks in advance

---

Ken Phillips

BOINC question? Look here



"The beginning is the most important part of the work." - Plato

I have a connection to two hosts over an encrypted VPN run over the Internet. It works fine, except that if the link at either end is busy the remote hosts drop out of BOINCView's list. I'd guess that if the response time you are getting from your remote machine is too great then you won't be able to make it work, even if the configuraton is correct all the way through.

Typical response time to PING for my set up is about 45ms. Try PING to your target machine and make that work. If you get long response times you probably won't succeed anyway.

Other than that, port 31416 is all you should need, but bear in mind that the source port allocated for BOINCView will almost certainly not be this, so your firewall needs an ACL something like:

permit tcp any host x.x.x.x eq 31416,

rather than a more prescriptive ACL.

---

<b>Giskard</b> - the first telepathic robot.

Perhaps the port forwarding of your router is making the request look like it's coming from 192.168.0.1 or 0.100 instead of the remote IP.

Thanks for your replies

@Alex

I thought about where the packets might appear to come from, to the remote host, after I posted earlier, so I added the internal IP of the remote router to the remote_host.cfg file as well - alas, it still it is still no go.

[b]@MikeW</B>

I hadn't thought of VPN, thanks for the idea, I established a VPN tunnel to the remote network, a ping to the remote workstations IP averages about 45ms, so that should be ok, the remote host then started spooling out errors about connections from a non-allowed rpc host, ha, one step closer! I added all the VPN addresses (192.168.0.4 - 192.168.0.15) to the remote_host.cfg file, way hey, success, at last, even managed to add the other host at the remote site, Marvellous, you're a star!!!!

However, my WAN internet connection was now down, and IP connections to my LAN machines were flakey, drat! What's up here I thought. On checking my routing table I discovered my default gateway was now the VPN tunnel, fixed that by routing vpn packets down the tunnel, everything else (alledgedly) goes to my router/dns/dhcp server, in spite of this, LAN lookups (via 'entire network') from my laptop (the monitoring machine) are still very slow.

Is VPN tunneling the only way to achieve this level of remote monitoring? Is there a simpler way?

I'm still mystified why traffic from port 31416 on that workstation still isn't getting back to me, without the tunnel.

Regarding the Access Control List, interpreting that into the terms of a standard adsl SPI modem/router, I put 31416 into the port triggering section, of my boundary router, which should (as I understand it) allow packets from any IP to any IP from port 31416 to port 31416, yes - no? It still won't work without the tunnel.

Running boincview on the remote host itself (using terminal services) shows boinc to be working happily, crunching away on LHC (when it gets work), CPDN, and SETI.

Still very puzzled, it would be great if it worked as I expected it to do without VPN, but I'm getting fed up of fighting it now, every alteration means rebooting the modem/routers, waiting, re-establishing links, trying, failing, ......

Does the version of the boinc client matter, the remote hosts are each running CC4.13, locally I'm using boincview 0.9.2b.

TTFN

---

Ken Phillips

BOINC question? Look here



"The beginning is the most important part of the work." - Plato

>>Running boincview on the remote host itself (using terminal services) shows boinc to be working happily, crunching away on LHC (when it gets work), CPDN, and SETI.

Boinc always allows the localhost to connect. ie.. 127.0.0.1 is always allowed.


Perhaps doublechecking your remote IP addy using www.network-tools.com would help.

When I was playing with boinc's RPC feature, I was able to telnet into my local host (although it hangs up on people)

From a command line, telnet
from telnet
open 192.168.0.100 31416

Pressing enter gives

<error>unrecognized op</error>
&#9829;

>>Is VPN tunneling the only way to achieve this level of remote monitoring? Is there a simpler way?

It should be possible to do this without the complexity of a VPN, but there are so many variables involved it'll be difficult to diagnose through this forum.

Things to check:
Firewall at monitoring end permits output on port 31416

Firewall at monitored end permits input to port 31416 from any port in the range occupied by the monitoring firewall. (Note that the port used by your monitoring machine will NOT be 31416)

There is a mapping from the public address range of the target firewall to the target machines.

Port address translation (if it's used) at the target firewall maps correctly to the target machine

Are addresses at the monitoring end translated? If so, the target firewall and remote_hosts.cfg needs to include the source public addresses, not the private ones. If you're translating addresses on input at the target end then remote_hosts.cfg needs those private addresses in the translated range instead.

There's probably more.

The best tool I had when I was running the BBC network was a tube of frog's blood and some chicken bones. They seemed as accurate as formal diagnostic tools at times. You might try reading tea leaves, too!

---

<b>Giskard</b> - the first telepathic robot.

PS

Ken, if you like I'll cast an eye over your firewall configurations. SPI isn't my line - I'm more Cisco & 3Com but I'll see what I can do. Drop a note to

blowjoggs at mail .com

and then post a note here to say you've done it.

I'll get back to you with a real mail address!

---

<b>Giskard</b> - the first telepathic robot.

IMO, MikeW has covered the issues perfectly in his last two posts. When you're using a NAT-router, the remote site will see the external IP of the "calling" router, not the internal IP of the machine doing the calling. It doesn't make any sense to configure private Class C addresses for anything other than VPN use because these addresses by their very definition are not routable over the 'net. Moreover, if your firewall allows connections from private Class C addresses on its external interface, things are looking very, very bad.

---

> >>Is VPN tunneling the only way to achieve this level of remote
> monitoring? Is there a simpler way?
>
> It should be possible to do this without the complexity of a VPN, but there
> are so many variables involved it'll be difficult to diagnose through this
> forum.
>
> Things to check:
> Firewall at monitoring end permits output on port 31416
>
> Firewall at monitored end permits input to port 31416 from any port in the
> range occupied by the monitoring firewall. (Note that the port used by your
> monitoring machine will NOT be 31416)
>
> There is a mapping from the public address range of the target firewall to
> the target machines.
>
> Port address translation (if it's used) at the target firewall maps
> correctly to the target machine
>
> Are addresses at the monitoring end translated? If so, the target firewall
> and remote_hosts.cfg needs to include the source public addresses, not the
> private ones. If you're translating addresses on input at the target end then
> remote_hosts.cfg needs those private addresses in the translated range
> instead.

Following a suggestion made by Alex, I actually ended up triple checking most of your suggestions above, all settings and IP addys at the firewall and networks at either end of my intended link seem to be AFAIK correct, with still no joy apart from tunneling. You suggest that the port address used locally would not be 31416, this could well be the problem, however, I can request traffic from port 80 on my intended remote host, and it comes back into my browser on port 80 (I assume), is this not the same principle?

> There's probably more.
>
> The best tool I had when I was running the BBC network was a tube of frog's
> blood and some chicken bones. They seemed as accurate as formal diagnostic
> tools at times. You might try reading tea leaves, too!
>

LOL, I was beginning to wonder if I might have to sacrifice something to the great god of networking, but my kitten is too cute, my other cat would have definite ideas of extreme and painful resistance, and I'm fresh out of beasties, I'm fairly sure that fish fingers would not cut the mustard:-)

None of my knowledge (small amount) retained from doing an intensive CCNA course seems to be helping here, if I understand what Trane is saying, then my problem (quite rightly) would be that I'm trying get packets from a remote private non-routable 192.168.0.0 network, over the internet, into my own private 200.200.0.0 network, via a local 10.10.10.0 stub network which is my WAN link, however packets intended and mapped for other ports on the remote machine such as FTP, VNC, HTTP, Terminal services, etc, all function OK, without a VPN tunnel, just not those intended for port 31416, a mystery indeed.

If I can figure a way to tabulate everything, and get a network diagram done, I'll probably take you up on your offer, coz, I'm determined to not let it beat me.

Again, thanks for your replies everyone.

Best wishes

---

Ken Phillips

BOINC question? Look here



"The beginning is the most important part of the work." - Plato

>> I can request traffic from port 80 on my intended remote host, and it comes back into my browser on port 80 (I assume), is this not the same principle?

Sorry Ken - you've missed this completely!

During the establishment of a TCP session the originating machine (I'll call it the client, but that's not really accurate) is allocated an unused port. The combination of IP address and port is called a socket and is different for every TCP session. It uses this socket to send a message to the target machine (called server for simplicity, but again this isn't really accurate) on the port specified for the protocol. For Telnet this would be 23, for HTTP it's 80, etc.
The server responds to this opening message with the its own socket for future communications in this session. All further communications between the two processes (note - processes, not machines) are conducted using these sockets, not the well-known port for the protocol.

This means:

1) The client never uses the well known port for its own socket.
2) The server changes its socket to one of its own choosing.

Thus in your comment above, only the packets setting up the session travel to port 80. All packets inbound to the client use a different port, and all subsequent outbound packets use a different port.

The socket is associated exclusively with a process on a machine - it's the method by which the target process is identified by the protocol stack. Think of two browsers running on a single PC, browsing different pages on the same web server. How could the traffic be differentiated if they all used port 80 at both ends?

The implications for firewalls are simply that ACLs must allow for the client port to be any value. The establishment of the session is tracked by the firewall, so the change of server socket is allowed by the ACL within the session.

Does this help?

Good luck!

---

<b>Giskard</b> - the first telepathic robot.

Sorry folks - duplicate post.

---

<b>Giskard</b> - the first telepathic robot.

> >> I can request traffic from port 80 on my intended remote host, and it
> comes back into my browser on port 80 (I assume), is this not the same
> principle?
>
> Sorry Ken - you've missed this completely!

I thought I must have done :-)

> During the establishment of a TCP session the originating machine (I'll call
> it the client, but that's not really accurate) is allocated an unused port.
> The combination of IP address and port is called a socket and is different for
> every TCP session. It uses this socket to send a message to the target machine
> (called server for simplicity, but again this isn't really accurate) on the
> port specified for the protocol. For Telnet this would be 23, for HTTP it's
> 80, etc.
> The server responds to this opening message with the its own socket for future
> communications in this session. All further communications between the two
> processes (note - processes, not machines) are conducted using these sockets,
> not the well-known port for the protocol.
>
> This means:
>
> 1) The client never uses the well known port for its own socket.
> 2) The server changes its socket to one of its own choosing.

Ok, so the official port number is the 'knock on the door' to the correct protocol, etc, on the server, and on a natpt/spi firewall the generated responses are considered stateful if the port AND address changes have been tracked correctly, and 'match' a request generated at the client, otherwise the packet received at the client is dropped.

> Thus in your comment above, only the packets setting up the session travel to
> port 80. All packets inbound to the client use a different port, and all
> subsequent outbound packets use a different port.
>
> The socket is associated exclusively with a process on a machine - it's the
> method by which the target process is identified by the protocol stack. Think
> of two browsers running on a single PC, browsing different pages on the same
> web server. How could the traffic be differentiated if they all used port 80
> at both ends?

Very good, extremely valid point, by my reasoning above, of course this would be impossible, same IP, same port, oh dear - conflict; the received packet must find it's way back the correct host, so the address cannot change, therefore, the port must. It amazes me the level of stupidity that my supposed intelligence can stoop too.

> The implications for firewalls are simply that ACLs must allow for the client
> port to be any value. The establishment of the session is tracked by the
> firewall, so the change of server socket is allowed by the ACL within the
> session.

Meaning that unless I open every single port (within reason) on my firewall at home (no way!!!! I might be mad, but I'm not that mad), or do something cunning along the lines of a DMZ, then I cannot predict which port to open to receive the correct response from boincview, therefore, I'm stuck using a VPN tunnel, never mind, at least it does work, it could be worse, and I can access my home network from the remote one when I'm there :-)

I'll try to get my topology, routing tables, IP's, etc, drawn out for your perusal - In the meantime, do you know any really good incantations ('oh wata na siam' does not count!)

TTFN

---

Ken Phillips

BOINC question? Look here



"The beginning is the most important part of the work." - Plato

Hi, Ken.

> > Sorry Ken - you've missed this completely!
>
> I thought I must have done :-)

Heh. It happens. :o)

> Ok, so the official port number is the 'knock on the door' to the correct
> protocol, etc, on the server, and on a natpt/spi firewall the generated
> responses are considered stateful if the port AND address changes have been
> tracked correctly, and 'match' a request generated at the client, otherwise
> the packet received at the client is dropped.

Right. Now, the way you want to set things up is to set up your "remote" firewall to pass through port 31416 traffic directly to your "RPC BOINC client". On the BOINC client, use the RPC config text file to dictate which host is allowed to connect. This host IP address is the external IP address of the NAT router for the network in which your BOINCview system is operating. An example of this:

[ Edited to fix the formatting here, but it doesn't look right. Bah. ]

local BOINCview---router----------router----------RPC BOINC
192.168.1.22------203.216.70.70---123.123.123.1---10.1.2.3

It's a pretty simple NAT config. The local BOINCview machine doesn't need any special configuration, but take note that it's configured to connect to RPC BOINC's machine at 123.123.123.1, not 10.1.2.3. When the router gets the connect request at port 31316, it passes the connection request to 10.1.2.3, the BOINC machine. The RPC BOINC machine looks at its config file and sees the router IP address from the originating network....and the connection is accepted.

And that's the difference. With NAT, you use the external IP addresses for the routers. For VPN, you're using the local machine IP addresses.

Does this help?

trane

---

>port 31316,
>

Funny. the typo I always make is to type 31415.

Trane

>
> Right. Now, the way you want to set things up is to set up your "remote"
> firewall to pass through port 31416 traffic directly to your "RPC BOINC
> client". On the BOINC client, use the RPC config text file to dictate which
> host is allowed to connect. This host IP address is the external IP address of
> the NAT router for the network in which your BOINCview system is operating. An
> example of this:
>
> [ Edited to fix the formatting here, but it doesn't look right. Bah. ]
>
> local BOINCview---router----------router----------RPC BOINC
> 192.168.1.22------203.216.70.70---123.123.123.1---10.1.2.3
>
> It's a pretty simple NAT config. The local BOINCview machine doesn't need any
> special configuration, but take note that it's configured to connect to RPC
> BOINC's machine at 123.123.123.1, not 10.1.2.3. When the router gets the
> connect request at port 31316, it passes the connection request to 10.1.2.3,
> the BOINC machine. The RPC BOINC machine looks at its config file and sees the
> router IP address from the originating network....and the connection is
> accepted.

This is my remote port forwarding setup, the second column is source port, the third is destination port, the fourth is destination IP; you have explained it the way I thought it would/should work, but for whatever reason it does not, even when the remote_host.cfg contains my external IP addy, and the remote routers internal IP addy , the remote boinc seems to not even be complaining about dis-allowed connections, it's as if the packets don't hit it, or they are hitting it but not getting back through.

Just for confirmation the 192.168.0.1 address is correct for the remote boinc machine, the routers internal IP addy is 192.168.0.2, I don't know why, that's just the way it ended up when I set it up, and that's how it stayed since.

I think I'm going to try and figure out how far the packets are getting, then perhaps I can attack the problem a bit more meaningfully.

Bye now

---

Ken Phillips

BOINC question? Look here



"The beginning is the most important part of the work." - Plato

Bah humbug!

Thanks Trane for kicking the lazy one of my three remaining brain cells!

I added the external IP addy of my remote router, (which I would never have considered) to my remote crunchers remote_hosts.cfg file, guess what? It only works!!!

Simple solution right in front of me all the time, but, couldn't see the wood for the trees. Isn't it amazing how simple solutions can be so evasive?.

Now, where is that wall to bang my head against?

Thanks all for the help and sugestions.

[edit] now have my second remote cruncher on the same site connected to my local boincview, have mapped external port 31417 to internal port 31416 - marvellous!!! [/edit]

Best wishes,

---

Ken Phillips

BOINC question? Look here



"The beginning is the most important part of the work." - Plato

I'm guessing it's ok, assuming that 192.168.0.1 is your local network's seti box.

Perhaps the site you're monitoring from has firewall rules which disallow certain ports.
Perhaps if your router mapped incoming port 21 to your seti box's 31416... (something to try.

Looking at my personal firewall, I noticed something about boincview..
boincview opens up a new connection for each query, so maybe the router's in between your seti box and the remote boincview don't like the fact that there's multiple queries every few seconds.

Perhaps try setting the boincview polling period to 15 or more seconds.

Edit.. oh, never mind, you fixed it.

Well done Ken!


>>Meaning that unless I open every single port (within reason) on my firewall
>>at home (no way!!!! I might be mad, but I'm not that mad), or do something
>>cunning along the lines of a DMZ, then I cannot predict which port to open
>>to receive the correct response from boincview, therefore, I'm stuck using a
>>VPN tunnel, never mind, at least it does work, it could be worse, and I can
>>access my home network from the remote one when I'm there :-)

This might be redundant now, but...

Your local firewall generally will allow traffic from any port to any port for packets leaving the private network. There's no risk here. The remote firewall needs to permit traffic from any port to a specific port on traffic entering the private network. This works because the firewall tracks the changes to the sockets within a TCP session and allows the traffic through.

E.g.

Client requests HTTP page from server.

First packet leaves client on port a.b.c.d:x, going to server on e.f.g.h:80
(leaves private network, enters remote private network on port 80. Local firewall sees session being opened and starts tracking it. Remote firewall sees session being opened and starts tracking it).

Second packet leaves server on e.f.g.h:y, going to a.b.c.d:x. (Remote firewall sees packet leaving, notes change of socket in the session, opens temporary ACL entry to allow further packets in on new socket. Local firewall sees packet arriving and updates its ACL similarly)

Packets exchanged between client & server using sockets a.b.c.d:x and e.f.g.h:y set up during initial exchange. Both firewalls allow traffic as part of the session through their temporary ACL entries.

Client or server completes transfer, send final packet to close session. Firewalls see the last packet and tear down the temporary ACL entries.

>>
>>boincview opens up a new connection for each query
>>

yes - most apps will do this. You'd be surprised how many sessions are opened and closed while you're surfing the net. This is one of the handshaking overheads that slows down traffic on the web.

The unfortunate thing about all this is that it provides a simple method for a denial of service attack. The attacker generates numerous requests to open a session, but never completes them. The target of the attack opens session after session, eventually running out of available sockets. The orphaned sessions will eventually time out, but if the attack is sustained the sockets will be reused as soon as they are freed. Imagine thousands of machines all doing this and its easy to see how SCO, Microsoft, Worldpay and others can be taken down, even with their connectivity.

Hehe - have fun!

---

<b>Giskard</b> - the first telepathic robot.