Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 18 replies
  • Subscribers 28 subscribers
  • Views 1761 views
  • Users 0 members are here
Options
Suggested
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

BrentMagnant

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
  • 0

    Do you have a SD-WAN Rule on SiteB? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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. 

    __________________________________________________________________________________________________________________

  • 0 in reply to BrentMagnant

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

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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. 

  • 0 in reply to BrentMagnant

    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? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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.

  • 0 in reply to BrentMagnant

    I have a question. Do you MASQ/NAT the traffic on one XG for the tunnel? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Not intentionally. I haven't gone thru the NAT rules after the v18 upgrade though.

    Site A - 192.168.x.0/24,  Site B - 192.168.y.0/24

    Static route works... I Would expect a NAT/MASQ issue would show up there as wll.

  • 0 in reply to BrentMagnant

    Do you have a NAT Rule from Site A to Site B using SNAT? Anything to masq the traffic? 

    __________________________________________________________________________________________________________________

  • 0 in reply to BrentMagnant

    You should get in touch with Sophos Support to get your conntracks etc. analysed. What you could do, try to disable firewall acceleration to check, if this will actually have an impact. 

    __________________________________________________________________________________________________________________

Reply Children
  • 0 in reply to BrentMagnant

    console> system firewall-acceleration disable

    I do not expect to fix your issue, but its worth a shot. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    So I logged into the 2 firewalls, enabled my SDW routing, and disabled my static routes. And it worked. I cleared the CONNTRACK on both FWs and it still worked. Odd, since I hadn't many any changes. Failed over HA on one side, everything failed. I couldn't get the SDW routing to work no matter what I did, failed back, reset the VTI tunnels, CONNTRACK, etc. Put the manual routes back in and everything works. I don't know what the issue is, but it doesn't work!!!!    Argh!

Cookie Information Banner