[lug] openvpn & linksys router question

[David L. Anselmi]

Bear Giles wrote:
[...]
> Both systems are running openvpn. In this particular case it's P-t-P so 
> there's not really a 'server' and 'client'.  I've also been 
> experimenting with a true client/server model, but that just introduces 
> some additional complications.

Oh, OK.  To me client/server should be easier.  Not the openvpn part of 
it, but the rest of the networking (routes, firewall rules, etc) since 
almost every networking situation I see is client/server.

[...]
> BTW, the vpn traffic is UDP packets with identical source and destination ports.

Are you sure?  That would be one duplex socket.  But two simplex sockets 
would work the same way (each box sends to 1194 from a random port). 
But even if only 1194 is used for source and destination, the Linksys 
probably NATs the outgoing packets and changes the source port.

[...]
> It's P-t-P so either side should be able to initiate the connection.  
> I'm not seeing that, only one side is able to initiate the connection.

How do you know only the office can initiate?  (I believe you, just 
don't have a P-t-P setup to see for myself.)  Can you isolate the 
initiation so that it always happens on one side or the other (e.g., 
start one, wait for it to give up on initiating, then start the other)?

If only the office can initiate I'd guess that is the source of your 
problem.

Another possibility is that the NAT entry on the Linksys is timing out. 
  Regardless, maybe the Linksys is changing the source port on outbound 
packets unless it can associate them with an inbound one.

What happens when a packet to 1194, that should be from 1194, isn't? 
That's why client/server (where you know the client port is ephemeral) 
seems easier to me, you don't have to experiment to determine the 
behavior in unspecified cases.

If this is an odd interaction between P-t-P and NAT it would be worth 
Googling for and pointing out to Jim Yonan.  Maybe he can put in a 
workaround, or at least update the docs (which seem sparse on P-t-P) to 
say "don't do that".

Dave

P.S. It might be helpful to watch the traffic at the eth interface of 
each device while you investigate "who's initiating" and what gets to 
each side.  But you'd probably want to see that in Ethereal rather than 
tcpdump.  And don't assume too much, like source port will always be 1194.