Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 27 subscribers
  • Views 1344 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

Routing from SSL VPN to other Router for public IPs

MichaelWalter

Hello togehter,

i have some trouble for routing in a ssl vpn tunnel. for some details i attached an image.

the ssl-tunnel routes every packet to the sophos - so it is configured as a standard gateway. if the vpn client open google.de the client break out at the sophos WAN-side (works as expected)

then i have an internal network (10.19.x.x)which is reachable via cisco router. okay there is a route and firewall rule which allows this - works also as expected.

now i have a public IP (217.227.x.x) which must route via the cisco router. so i have a routing entry for that IPs. But nothing happened. I try to find out something with tcpdump and i saw that the traffic for that IP came in but there ist no outgoing packet. wether the sophos WAN or to the cisco Router.

I try to configure dedicated networks for the SSL-VPN settings and saw that this works. But it is mandatory for this constellation, that some public IPs (217.227.x.x) must reachable from the cisco side.

 

what i made worng?

thanks in advance

michael



This thread was automatically locked due to age.
  • 0

    behaviour is in Version 17.5.12 and actual v18

  • 0 in reply to MichaelWalter

    Lets see. 

    Now the new feature of SD-WAN Policy Based Routing comes in place. 

    As we did routing for the last decades, it follows certain RFC norms. 

    SD-WAN PBR can actually do what every you want without any limitations or RFCs. So you can actually overwrite RFC behaviors, if you want and that quite easily.

     

    What you can do: (V18 only) go to PBR and create a route, which follows your needed requirements: 

    Traffic coming from, going to, should use following route. 

    PS: You can simply create a Gateway to tell XG to route the traffic to the Cisco router. 

     

    As you have your NAT already in place, this is fine. 

     

    PBR routing will actually match and do what every you want, if it is useful or not. 

    So be careful in case of "ANY" in PBR. As ANY could match... ANY traffic, it could destroy internal traffic. 

     

  • 0 in reply to LuCar Toni

    Good morning,

    i try to create a SD-WAN PBR with version 18 as you can see here:

    but nothing happened. if i try to open this website - i get a timeout.

    here is the tcpdump output for url: meineip.de

    other sites break out at the WAN side of the sophos, if i disable this rule, then the site: meinip.de is reachable

    btw: no firewall rule block this traffic. i guess that this rule is enough?!?

     

    bye michael

  • 0 in reply to MichaelWalter

    This cisco router is not connected via IPsec, isnt it? 

    So it is a "real route" to the cisco? 

    Because looks like XG is dropping the traffic. Try to perform a drop packet capture "drppkt" on XG with filter drppkt | grep 10.81.234.6 

  • 0 in reply to LuCar Toni

    the cisco is connected via the internal LAN. so no IPSec connection.

    here the output of the droppacket:

    SFVH_SO01_SFOS 18.0.0 GA-Build354.HF052220.1# drppkt | grep 10.81.234.6

    2020-06-22 10:18:12 0128021 IP 10.81.234.6.51855 > 213.133.104.71.443 : proto TCP: S 2126864990:2126864990(0) win 64240 checksum : 38148
    Date=2020-06-22 Time=10:18:12 log_id=0128021 log_type=Firewall log_component=SSL_VPN log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=tun0 out_dev= inzone_id=5 outzone_id=1 source_mac= dest_mac= bridge_name= l3_protocol=IPv4 source_ip=10.81.234.6 dest_ip=213.133.104.71 l4_protocol=TCP source_port=51855 dest_port=443 fw_rule_id=N/A policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=1 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_done=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 nat_id=0 cluster_node=0 inmark=0x0 nfqueue=0 gateway_offset=0 connid=465439552 masterid=0 status=0 state=1, flag0=18014948267393024 flags1=0 pbdid_dir0=1 pbrid_dir1=0

     

    so it is dropped - but why?