Re: Issue with point to point VPNs behind NAT and asymmetric traffic

2019-06-26 Thread Anurag Bhatia
Controls source route verification > net.ipv4.conf.default.rp_filter = 0 > # Do not accept source routing > net.ipv4.conf.default.accept_source_route = 1 > > > > -Original message- > *From:* Anurag Bhatia > *Sent:* Wed 06-12-2019 04:45 pm > *Subject:* Issue

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

2019-06-15 Thread Grant Taylor via NANOG
On 6/15/19 2:06 PM, William Herrin wrote: This is probably enabled on one or both ends: http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html Do some distros enable this now? I thought it was disabled by default. Disable it. Or make sure it's using loose (2) filtering. rp_filter

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

2019-06-15 Thread William Herrin
On Wed, Jun 12, 2019 at 2:45 PM Anurag Bhatia wrote: > > > I am running two site to site VPNs (wireguard now, OpenVPN earlier) between my home and a remote server over two different WAN links. Both WAN links are just consumer connections - one with public IP and one with CGNATed IP. > The redundan

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

2019-06-15 Thread Anurag Bhatia
Hi I did disable firewall at both ends to test and the result was similar. Please note firewall rules do allow the UDP ports to establish the VPN link and inside the link, there aren't any firewall restrictions. However, as I said I wonder if or if not the CGNAT device of my link 2 will allow the

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

2019-06-12 Thread Grant Taylor via NANOG
On 6/12/19 3:44 PM, Anurag Bhatia wrote: Hello everyone, Hi, I am running two site to site VPNs (wireguard now, OpenVPN earlier) between my home and a remote server over two different WAN links. Both WAN links are just consumer connections - one with public IP and one with CGNATed IP. Oka

RE: Issue with point to point VPNs behind NAT and asymmetric traffic

2019-06-12 Thread Jerry Cloe
Linux by default (regardless of firewall rules) will not accept a packet on an interface when the source of that packet "should" be on another interface according to the current route table (in other words, you're doing asymetric routing).   Easy fix:   # Controls source route verification net

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

2019-06-12 Thread Ross Tajvar
My guess is something is doing stateful filtering. If you send a SYN down one link and the SYN-ACK comes back a different link, the receiving firewall will discard it as bogus. You should be able to test this by doing pcaps to confirm the traffic is arriving (though I'm not familiar with WireGuard

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

2019-06-12 Thread blakangel
Could it be as simple as a stateful firewall? Anurag Bhatia wrote on 6/12/2019 14:44: Hello everyone, Trying to get my head around a certain unexpected behaviour. I am running two site to site VPNs (wireguard now, OpenVPN earlier) between my home and a remote server over two different WAN l

Issue with point to point VPNs behind NAT and asymmetric traffic

2019-06-12 Thread Anurag Bhatia
Hello everyone, Trying to get my head around a certain unexpected behaviour. I am running two site to site VPNs (wireguard now, OpenVPN earlier) between my home and a remote server over two different WAN links. Both WAN links are just consumer connections - one with public IP and one with CGNATe