Guest User!

You are not Sophos Staff.

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

    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. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Here the conntrack output:

    XG450_WP02_SFOS 18.5.2 MR-2-Build380# conntrack -L -s 3.3.3.20 -d 1.1.1.3
proto=icmp     proto-no=1 timeout=29 orig-src=3.3.3.20 orig-dst=1.1.1.3 type=8 code=0 id=336 packets=8 bytes=224 reply-src=2.2.2.2 reply-dst=3.3.3.20 type=0 code=0 id=336 packets=8 bytes=224 mark=0x0 use=1 id=1397796288 masterid=0 devin=Port1 devout=Port3 nseid=0 ips=7 sslvpnid=0 webfltid=0 appfltid=7 icapid=0 policytype=1 fwid=160 natid=34 fw_action=1 bwid=0 appid=0 appcatid=0 hbappid=0 hbappcatid=0 dpioffload=0xc sigoffload=0 inzone=2 outzone=3 devinindex=50 devoutindex=49 hb_src=0 hb_dst=0 flags0=0xa0002200008 flags1=0x50400800000 flagvalues=3,21,25,41,43,87,98,104,106 catid=0 user=0 luserid=0 usergp=0 hotspotuserid=0 hotspotid=0 dst_mac=xx:xx:xx:xx:xx:xx src_mac=xx:xx:xx:xx:xx:xx startstamp=1645365204 microflowid[0]=5545 microflowrev[0]=39 microflow[1]=INVALID hostrev[0]=1 hostrev[1]=0 ipspid=0 diffserv=0 loindex=50 tlsruleid=0 ips_nfqueue=7 sess_verdict=0 gwoff=0 cluster_node=0 current_state[0]=62456 current_state[1]=62456 vlan_id=0 inmark=0x8003 brinindex=0 sessionid=6973 sessionidrev=29746 session_update_rev=1 dnat_done=3 upclass=0:0 dnclass=0:0 pbrid_dir0=0 pbrid_dir1=0 nhop_id[0]=65535 nhop_id[1]=65535 nhop_rev[0]=0 nhop_rev[1]=0 conn_fp_id=NOT_OFFLOADED
conntrack v1.4.5 (conntrack-tools): 1 flow entries have been shown.

    The XG is configured from scratch. No migration.

    This is the SD-WAN-Policy.

  • +1 in reply to Markus Ottmann1

    The issue is: Your PBR Rule does not match. 

    That is the filter you should apply: orig-src=3.3.3.20 orig-dst=1.1.1.3

    You see in the Conntrack the NAT is applied:reply-src=2.2.2.2 reply-dst=3.3.3.20

    Those filters indicate no PBR Rule was applied: pbrid_dir0=0 pbrid_dir1=0 

    And PBR Filters will always applied, even if the route precedence is not set. 

    Maybe the Interface ports are not correct? The traffic is from Port1. You match Port2 on your PBR. 

    __________________________________________________________________________________________________________________

Reply
  • +1 in reply to Markus Ottmann1

    The issue is: Your PBR Rule does not match. 

    That is the filter you should apply: orig-src=3.3.3.20 orig-dst=1.1.1.3

    You see in the Conntrack the NAT is applied:reply-src=2.2.2.2 reply-dst=3.3.3.20

    Those filters indicate no PBR Rule was applied: pbrid_dir0=0 pbrid_dir1=0 

    And PBR Filters will always applied, even if the route precedence is not set. 

    Maybe the Interface ports are not correct? The traffic is from Port1. You match Port2 on your PBR. 

    __________________________________________________________________________________________________________________

Children
  • 0 in reply to LuCar Toni

    Now it works. The source interface have to be 1.1.1.3.

    The ports are correct, because the rule is only for the reply packets.

    And the question remains. Why I have to enable asymmetric routing for reply-packets and implement a PBR rule to prevent asymmetric routing?

    Many thanks for the support.

Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?