SSLVPN Routing

Running Firebox M370, latest updates.

We switch our SSLVPN from bridged mode to routed and also enabled Split Tunnel.

The IP range for the routed mode is new on our network, 172.16.13.X. Client on the SSLVPN can login and ping resources on the 'main' network (172.16.10.x).

The issue, which I am not sure it's a real issue or not is, client on the main network cannot ping SSLVPN clients. The ping is routed out to the Internet (tracert). We can ping and get replies from, which I am assuming is the gateway on the Firebox.

Should I add a route on the M370 to point to the SSLVPN netowrk?


  • Options

    XTM knows how to route to subnets defined to it, including the SSLVPN subnet.

    When I turn off the firewall on my Win 10 PC, I can ping the SSLVPN virtual IP addr of my PC from my firewall.
    Look at the firewall rules on your PCs.

  • Options

    Bruce - Thanks for the reply. When i run a tracert from the main network to, which is a person connected to the SSLVPN, the packet hits the firewall and then is routed out through our Internet service -

    Tracing route to over a maximum of 30 hops

    1 <1 ms <1 ms <1 ms
    2 <1 ms <1 ms <1 ms 198.36.ABC.ABC
    3 63-158-247-221.dia.static.qwest.net [] reports: Destination net unreachable

  • Options

    No idea why you are seeing this routing.
    Are you sure that the only place that you have defined the 172.16.10.x subnet is for SSLVPN? does not seem to be a reasonable gateway addr for a SSLVPN subnet.

    My FSM -> Status Report shows this for my SSLVPN defined subnet:

    tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
    inet addr: P-t-P: Mask:

    And there is this entry in the Status Report IPv4 Routes table: U 0 tun0

  • Options
    edited March 2020

    I do have those same entries in the status report. Our SSLVPN range is 172.16.13.X. 172.16.10.X is our 'main network'.

    The following was in the logs - 2020-03-19 10:46:56 Allow src_ip= dst_ip= pr=icmp src_port= dst_port= src_intf=0-MainNetwork dst_intf=5-FiberWAN msg=Allowed pckt_len=92 ttl=2 policy=(Ping-00) proxy_action= proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="198.36.ABC.ABC" dst_user="Todd@Active Directory" route_type="SD-WAN" Traffic

    Thanks for looking!

  • Options

    No idea.
    Time for a support incident - a WG rep can look at your config and help resolve this for you.
    Should you find an answer, please post it.

  • Options

    Thanks for your time! I will update when I find a solution.

  • Options

    Just to close the loop here. I spoke with Tech Support. The issue was with our Ping Policy. It was routing those packets per the SD-WAN policy. After unchecking the Route outbound traffic using SD-WAN Based Routing, we were able to ping sslvpn clients.

    Thanks again for the help!

Sign In to comment.