Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

XG v18 MR-3 SDWAN Policy Routing

Good evening,

I have built out an IPSEC tunnel for VTI. The tunnel is up, the interfaces are up, the gateways are up.

Lets call them SITEA and SITEB both with HA (active-passive)

I have created an SDWAN policy route on each end, but I cannot ping between sites. If I make a manual route, it works fine, so I believe I can rule out firewall rules, etc. 

Packet capture at SiteA shows the ping leaving SiteA. The packet capture on SiteB shows the ping arriving, but the ping response is routed out the WAN.

I have already 

  • set routing sd-wan-policy-route system-generate-traffic enable
  • set routing sd-wan-policy-route reply-packet enable
  • system route_precedence set sdwan_policyroute vpn static

My policy route is set to any interface, any source, to destination network.

It all looks like it should be working, but it is not. Any ideas?

Thanks,
Brent



This thread was automatically locked due to age.
Parents
  • Do you have a SD-WAN Rule on SiteB? 

  • The important part to understand is: SD-WAN PBR will break with the network expectation of the last decades. You can "force" XG to route those packets to other interfaces.

    If you enable "reply-packets", it will even route the packets, based on a existing connection, to another Interface and not to the interface, which the packets originated. 

    For years, this setup was feared as asymmetric routing and bad practice. But starting with SD-WAN, you actually do not care, how those packets get to the destination, as long they arrive there. 

  • Yes, I have SDWAN on both sides. Originating traffic from each LAN is routing as expected. However, return traffic (PING response) is not being direct properly. Reply traffic is going out the WAN instead of the VTI. 

  • Disable Reply traffic. That should do the trick on both ends. 

  • I started with that, it was off by default as these were v17 upgrades. Reply traffic went out the WAN. Enabled reply, reply traffic still went out the WAN.  These configs are very straight forward but with SDWAN PBR the traffic won't go back. As soon as I make a static route, everything is fine but I can't do tunnel failover with static routes.

    The question is:  Originating traffic follows PBR, but why doesn't the reply traffic follow the PBR rules, with or without reply traffic enabled in the CLI?

    There is an HR pair at both ends. 

  • Reply Traffic switch should be disabled. This should give you the desired behavior.

    What you can do: Set it to disable and flush the conntrack (conntrack -F). This will reset all connections. Based on this, it should be working. 

    The switch can actually be applied to new traffic. 

    PS: Do you have any migrated SD-WAN Rules still there? 

  • We don't have any migrated SDWAN rules. We were using were using straight IPSEC site-to-site tunnels. We are moving them to VTI for better failover control.

    I will try this tonight, but I don't expect it it will make a difference. That is how it was before.

    I did notice last night that when I switched HA to the passive device (failed over), traffic did work as expected for a time. I have to wonder if VTI/PBR works as expected in HA setups.

Reply
  • We don't have any migrated SDWAN rules. We were using were using straight IPSEC site-to-site tunnels. We are moving them to VTI for better failover control.

    I will try this tonight, but I don't expect it it will make a difference. That is how it was before.

    I did notice last night that when I switched HA to the passive device (failed over), traffic did work as expected for a time. I have to wonder if VTI/PBR works as expected in HA setups.

Children