nanog mailing list archives

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


From: Anurag Bhatia <me () anuragbhatia com>
Date: Wed, 26 Jun 2019 18:13:53 +0530

The issue is resolved by tweaking the route validation.

Added following my ansible playbook for both ends:

      - name: Enable Controls source route verification
        sysctl:
          name: net.ipv4.conf.default.rp_filter
          value: '0'
          sysctl_set: yes

      - name: Do not accept source routing
        sysctl:
          name: net.ipv4.conf.default.accept_source_route
          value: '1'
          sysctl_set: yes


and it works fien now.

Thanks, everyone for the inputs.

On Thu, Jun 13, 2019 at 3:55 AM Jerry Cloe <jerry () jtcloe net> wrote:

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.ipv4.conf.default.rp_filter = 0
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 1



-----Original message-----
*From:* Anurag Bhatia <me () anuragbhatia com>
*Sent:* Wed 06-12-2019 04:45 pm
*Subject:* Issue with point to point VPNs behind NAT and asymmetric
traffic
*To:* NANOG Mailing List <nanog () nanog org>;
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
CGNATed IP.
The redundancy here is taken care of by the OSPF running via FRR on both
ends.


The unexpected behaviour I get is that if I set OSPF cost to prefer say
link1 between home -> server and prefer link 2 between server -> home then
connectivity completely breaks between the routed pools. The point to point
IPs stay reachable (which is over expected links i.e symmetric via both
ends). As long as both ends prefer link1 or link2, it works fine. At first,
I thought it had to do something with NAT but still can't understand how.
Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is
always up. Any idea why asymmetric packets are being dropped here?
This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is
still the same when I moved everything to Wireguard for VPN + FRR for
routing + OSPF.




Thanks.


--


Anurag Bhatia

anuragbhatia.com



-- 


Anurag Bhatia
anuragbhatia.com

Current thread: