Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 1294 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

unclear XG routing decision

LHerzog

We notice a strange routing decision of the XG to networks not routed by the XG itself.

This traffic is forwarded to an IP address I cannot find any routes to. Also the XG does not even have an IP address in the network range of that IP address.

If I tracert a host of such a host from the foreign network while I'm connected to the XG, I can see the traffic is going to the XG and the next hop is the strange IP address of the other router.

I did not find NAT rules nor did I find local IP routes on the XG.

What can I do to find out why XG forwards the traffic to this particular router IP?



This thread was automatically locked due to age.
Parents
  • 0

    Build up a session and check the conntrack. Do it with conntrack -E |grep ip 

    Then check if there are routing decisions in there. 

    Try route -n to check if there is any route for this traffic. 

  • 0 in reply to LuCar Toni

    thanks 

    so i did the conntrack and see no NAT applied by what about routes?

    Strange enough, when I traceroute to the destination IP from XG - the traffic is routed through a well known IP address.

    route -n does not list the IP or network address of the next HOP seen from the clients. Of course the clients do not have local routes to this network.

    XG430_WP02_SFOS 18.0.4 MR-4# conntrack -E |grep 172.16.xxx.xxx
    [NEW] proto=icmp     proto-no=1 timeout=30 orig-src=10.242.xxx.xxx orig-dst=172.16.xxx.xxx type=8 code=0 id=1 [UNREPLIED] reply-src=172.16.xxx.xxx reply-dst=10.242.xxx.xxx type=0 code=0 id=1 id=2012978048 masterid=0 devin=tun0 devout=lag0 nseid=0 ips=0 sslvpnid=1 webfltid=0 appfltid=0 icapid=0 policytype=1 fwid=14 natid=0 fw_action=1 bwid=0 appid=0 appcatid=0 hbappid=0 hbappcatid=0 dpioffload=0xd sigoffload=0 inzone=5 outzone=9 devinindex=111 devoutindex=24 hb_src=0 hb_dst=0 flags0=0x40a0000200008 flags1=0x10000800000 flagvalues=3,21,41,43,50,87,104 catid=0 user=153 luserid=142 usergp=6 hotspotuserid=0 hotspotid=0 dst_mac=45:00:00:5c:6e:79 src_mac=00:00:02:01:75:06 startstamp=1613484996 microflow[0]=INVALID microflow[1]=INVALID hostrev[0]=0 hostrev[1]=0 ipspid=0 diffserv=0 loindex=24 tlsruleid=0 ips_nfqueue=0 sess_verdict=0 gwoff=0 cluster_node=0 current_state[0]=1075 current_state[1]=0 vlan_id=0 inmark=0x0 brinindex=0 sessionid=3402 sessionidrev=53881 session_update_rev=1 dnat_done=0 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
 [UPDATE] proto=icmp     proto-no=1 timeout=30 orig-src=10.242.xxx.xxx orig-dst=172.16.xxx.xxx type=8 code=0 id=1 reply-src=172.16.xxx.xxx reply-dst=10.242.xxx.xxx type=0 code=0 id=1 id=2012978048 masterid=0 devin=tun0 devout=lag0 nseid=0 ips=0 sslvpnid=1 webfltid=0 appfltid=0 icapid=0 policytype=1 fwid=14 natid=0 fw_action=1 bwid=0 appid=0 appcatid=0 hbappid=0 hbappcatid=0 dpioffload=0xd sigoffload=0 inzone=5 outzone=9 devinindex=111 devoutindex=24 hb_src=0 hb_dst=0 flags0=0x40a0000200008 flags1=0x10000800000 flagvalues=3,21,41,43,50,87,104 catid=0 user=153 luserid=142 usergp=6 hotspotuserid=0 hotspotid=0 dst_mac=45:00:00:5c:6e:79 src_mac=00:00:02:01:75:06 startstamp=1613484996 microflow[0]=INVALID microflow[1]=INVALID hostrev[0]=0 hostrev[1]=0 ipspid=0 diffserv=0 loindex=24 tlsruleid=0 ips_nfqueue=0 sess_verdict=0 gwoff=0 cluster_node=0 current_state[0]=1075 current_state[1]=1075 vlan_id=0 inmark=0x0 brinindex=0 sessionid=3402 sessionidrev=53881 session_update_rev=1 dnat_done=0 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
^Cconntrack v1.4.5 (conntrack-tools): 7069 flow events have been shown.

    what's nhop_id[1]=65535?

  • 0 in reply to LHerzog

    Somebody is answering this Ping. Your Route points to your lag0. What about ip r g IP 172.16. 

    What should be the expected output? 

  • 0 in reply to LuCar Toni

    I found out that if I traceroute from the XG and specify a source IP and chose a gateway IP the client computers are using (e.g. SSL VPN) the XG uses the same wrong IP as first hop.

    ip route command shows the correct IP as first hop: 172.16.yyy.1

    XG430_WP02_SFOS 18.0.4 MR-4# ip r g 172.16
    172.16.0.0 via 172.16.yyy.1 dev lag0 src 172.16.yyy.2 uid 0
        cache

Reply
  • 0 in reply to LuCar Toni

    I found out that if I traceroute from the XG and specify a source IP and chose a gateway IP the client computers are using (e.g. SSL VPN) the XG uses the same wrong IP as first hop.

    ip route command shows the correct IP as first hop: 172.16.yyy.1

    XG430_WP02_SFOS 18.0.4 MR-4# ip r g 172.16
    172.16.0.0 via 172.16.yyy.1 dev lag0 src 172.16.yyy.2 uid 0
        cache

Children
No Data