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 172.16.13.1, which I am assuming is the gateway on the Firebox.
Should I add a route on the M370 to point to the SSLVPN netowrk?
0
Sign In to comment.
Comments
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.
Bruce - Thanks for the reply. When i run a tracert from the main network to 172.16.13.5, 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 172.16.13.5 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 172.16.10.253
2 <1 ms <1 ms <1 ms 198.36.ABC.ABC
3 63-158-247-221.dia.static.qwest.net [63.158.247.221] reports: Destination net unreachable
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?
172.16.10.253 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:192.168.222.1 P-t-P:192.168.222.1 Mask:255.255.255.0
And there is this entry in the Status Report IPv4 Routes table:
192.168.222.0 0.0.0.0 255.255.255.0 U 0 tun0
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=172.16.10.42 dst_ip=172.16.13.2 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!
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.
Thanks for your time! I will update when I find a solution.
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!