Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 28 subscribers
  • Views 2896 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

Asymmetric routing

Markus Ottmann1

Hi community,

for reasons of simplification let´s assume that our XG450 (SFOS 18.5.2 MR-2-Build380) has 4 ports configured:

  • Port 1 - Zone WAN - IP 1.1.1.2/24
    Gateway is 1.1.1.1
    Additional Alias: 1.1.1.3/32
  • Port 2 - Zone DMZ1 - IP 2.2.2.1/24 used for a special webservice
  • Port 3 - Zone DMZ2 - IP 3.3.3.2/24 direct connection to partner company but we are not using their default gateway in XG. We only use this to reach some devices in their network.
  • Port 4 - Zone LAN - IP 4.4.4.1/24

The additional alias address masks a webservice via DNAT rule in the DMZ1 (i. e. 2.2.2.2)

When our partner company try to use our webservice the request packets are routed from 3.3.3.0/24 over their gateway 3.3.3.1 to the internet and come in via 1.1.1.1. That is the preferred way because we don´t want to force our partner to set a static route.

But the answer packets are using the direct connected interface 3.3.3.2 to reach the original source.

console> show routing sd-wan-policy-route reply-packet
SD-WAN policy route is turned off for reply packets.

console> system route_precedence show
Routing Precedence:
1.  VPN routes
2.  SD-WAN policy routes
3.  Static routes

I´ve configured a SD-WAN policy:

Incoming Interface: Port 2 - DMZ1 - 2.2.2.1
Source networks: 2.2.2.0/24
Destination networks: 3.3.3.0/24
Primary gateway: WAN Gateway

.. and a SNAT rule with same source and destination networks and a translated source of 1.1.1.3 and outbound interface WAN Gateway.

In Sophos XG help I found this text:

Reply packets: Sophos Firewall enforces symmetric routing on WAN interfaces for reply packets. These packets use the same WAN interface as the original packets.

But that is not what I am seeing within a packet capture. The reply packets are allways leaving our XG over the direct connected interface. As a result, the app that addresses the web service only out of the partner network does not work. From internal or other external sources we have no problems.

 



This thread was automatically locked due to age.
  • 0

    Why would you do this in the first place? I mean you actually implementing a bad network design. 

    __________________________________________________________________________________________________________________

  • 0

    Hi,

    I had the same problem as you with my vpn concentrator to join a remote site, you can try this:

    set advanced-firewall bypass-stateful-firewall-config add source_network xxx.xxx.xxx.xxx source_netmask xxx.xxx.xxx.xxx dest_network xxx.xxx.xxx.xxx dest_netmask xxx.xxx.xxx.xxx

  • 0 in reply to LuCar Toni

    This was not really helpful nor an answer I would have expected on a previously considered high quality community forum. I know that this construct does not fit to an optimal best practice design guide. But sometimes you have to find a way to connect many different and not homogene environments together. I only want to know why the XG does not behave as expected and described or if I misunderstood something.

  • 0 in reply to Markus Ottmann1

    SD-WAN Reply Packets are applied on the current statement of the packet.

    1.1.1.1:12345 talks to 2.2.2.2:443 

    Packet back: 2.2.2.2:443 to 1.1.1.1:12345 

    Based on the Packet flow, you need to apply the SD-WAN on the packet back. (Source Port 443, Destination Port 12345 = High Port). 

    Still do not do this. It will get messy really quick. 

    __________________________________________________________________________________________________________________

  • 0

    Hi,

    Basically as per your description, you want to route reply packets via WAN gateway instead of directly connected Port 3 - Zone DMZ2 and for that you have configured SD-WAN.

    console> show routing sd-wan-policy-route reply-packet
    SD-WAN policy route is turned off for reply packets.

    As per above output, sd-wan-policy-route will not get applied to reply packet so have you checked by enabling sd-wan-policy-route for reply-packet

    Regards,
    Hardik R

     
  • 0 in reply to HardikR

    I think that is my problem. I don´t want asymmetric routing. I only want that reply packets go the same way backwards (over the WAN link) as they arrived. I expect this should be the normal behavior from the XG, but doesn't seem to be the case. The SD-WAN policy and the SNAT rule were my attempts to solve this, but it doesn´t work.

    I´ll give it a try to turn on SD-WAN policy for reply packets over the evening.

  • 0 in reply to HardikR

    No luck with "set routing sd-wan-policy-route reply-packet enable".

    The reply packets always go through the direct attached interface. I´m not able to bring the XG to route the reply packets out of the same interface they arrived.

    Here you can see a packet capture of a simple ping (the real interface names and IPs are adjusted for privacy reasons).

    2022-02-16 17:10:40
    Port 2
    Port 3
    IPv4
    1.1.1.3
    3.3.3.20
    ICMP
    --
    34
    160
    Forwarded
    -
    2022-02-16 17:10:40
    Port 2
    IPv4
    2.2.2.2
    3.3.3.20
    ICMP
    --
    0
    0
    Incoming
    -
    2022-02-16 17:10:40
    Port 1
    Port 2
    IPv4
    3.3.3.20
    2.2.2.2
    ICMP
    --
    34
    160
    Forwarded
    -
    2022-02-16 17:10:40
    Port 1
    IPv4
    3.3.3.20
    1.1.1.3
    ICMP
    --
    0
    0
    Incoming
    -

    I want the top packet to leave on Port 1 and not 3.

  • 0 in reply to Markus Ottmann1

    Can you show us your SD-WAN PBR? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Please look at my first posting.

  • 0 in reply to Markus Ottmann1

    Check the conntrack in Advanced Shell and check for the entry for this specific entry. And please share a Screenshot of this rule. Do you have a migrated SD-WAN Rules. 

    __________________________________________________________________________________________________________________

Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?