Hi,

On Mon, Feb 09, 2015 at 02:55:02PM -0500, Jeff Mitchell wrote:
> On Mon, Feb 9, 2015 at 1:22 PM, Gert Doering <g...@greenie.muc.de> wrote:
> > This is unlikely to be the issue.  It's most likely "some program
> > received a packet on the eth0 address, responded to it, and the return
> > route points to the VPN session" - in which case the packet is sourced
> > from the eth0 address (always reply from the address you've been
> > contacted on)...
> 
> Ah. I can try whittling down which program might be doing that. I
> figured that this was related to some way that OpenVPN was handling
> its traffic, but it makes sense that some program is just not behaving
> correctly and doing what you suggested.

Well, the program *is* behaving correctly - it's being talked to, and it
responds.  It has no way to "properly" respond with anything else than
the address it was connected on, and programs have no influence on routing...

You can work around this by using "ip rule" settings to force packets
sourced from eth0 out the LAN default gateway, but it might not be worth
the effort if everything else is working well enough.

> >> The client is inside a VM running on a laptop. When the client
> >> connects, the address OpenVPN sees is the address of the host, which
> >> makes sense given that the VM is using a NATed connection:
> >
> > My bet is on the NAT.  If NAT state is lost, and the next packet ends
> > up on a different external IP address or port, the server won't recognize
> > you anymore ("no idea who that client is, drop packet").
> 
> Makes sense, although I'm not sure what the issue would be. 

NAT table entries expiring, or NAT rules being reloaded and flushing state
at that.

[..]
> > If it's NAT state, and you can't fix the NAT, OpenVPN 2.3.7 on the
> > client side and "git master" on the server side will bring a solution
> > (TLS floating using peer-id).  But 2.3.7 is not released yet and we're
> > ironing out the last wrinkles on the server side.
> 
> Any chance "float" on the server side would help? I have it on the
> client side and the documentation made me think it's a
> client-side-only option but maybe it isn't?

It's a peer-to-peer option :-) - so it works on the client but not on the
server.

> Regardless, I could potentially try out TLS floating as suggested --
> can you point towards any documentation about it (or perhaps the man
> page in git master is already up-to-date)?

It will just magically happen (git master on server, git master or 2.3.6
on client), but is not working correctly yet for some corner cases so
there will be some more commits upcoming.  When 2.3.7 is released (soon)
everything should work nicely.

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             g...@greenie.muc.de
fax: +49-89-35655025                        g...@net.informatik.tu-muenchen.de

Attachment: pgpQDECYljSFs.pgp
Description: PGP signature

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to