VPN SSL vs Bridge
Hello,
I have an SSL VPN on firewall A, but this VPN does not communicate with the bridge on firewall B. The mode of this VPN is “Route VPN Traffic.” In this case, should I use “Bridge VPN Traffic” instead? Selecting the bridge between A and B?
Thank you.
0
Sign In to comment.
Comments
“Route VPN Traffic” is what you need.
What option is selected on the SSLVPN setup on your firewall?
. "Force all client traffic through the tunnel"
or
. Specify allowed resources
If "Specify allowed resources", does that list include the subnet on site B?
Please explain the connection for "the bridge between A and B".
Hello Bruce, the force option is disabled. All addresses from site A and site B are configured, but even so, the VPN does not route the traffic. We noticed that the client connected to the VPN at site A cannot reach the bridge gateway IP. On site B, even with a route to the gateway IP, it did not advance to one of the next hops, but we will test this VPN configuration using the bridge. From what we understand, this function is precisely for this scenario we have.
Thank You.
From the docs:
"Select Bridge VPN Traffic to bridge SSL VPN traffic to a network you specify. When you select this option, you cannot filter traffic between the SSL VPN users and the network that the SSL VPN traffic is bridged to."
With this option, the SSLVPN client will only get access the specific subnet that you specify in the SSLVPN setup.
Care to explain your "bridge" connection between the 2 firewalls?
Hello Bruce,
Is it necessary to force the connection through the tunnel for this routing to work using the “Route VPN Traffic” option? The “Bridge VPN Traffic” option seems to make more sense to us, as we have two Firebox M370s at each site, and the Bridge option is used between them by WatchGuard.
What happens in the network route test is that from site B, it does not reach the gateway of the bridge at site A, although a host from the subnet at site B can normally reach the host at site A. In summary, we have a bridge between the network at site A (172.16.111.0) and the network at site B (172.16.110.0), but the VPN network at site A (172.16.113.0) does not communicate with the network 172.16.110.0. We created a route at site B to the gateway of the bridge, but it stops at the gateway of the bridge at site B.
Thank You.
“Route VPN Traffic” allows the SSLVPN client to access other subnets than the virtual IP subnet set in the SSLVPN setup.
“Bridge VPN Traffic” will not allow access other subnets than the subnet specified in the SSLVPN setup.
Do you have a route to 172.16.113.0 at site B?
Bruce,
Yes, the route uses the same network gateway as site A.
Routes in Firebox at site B:
172.16.111.0/24 > 172.16.110.254 - OK, bridge working.
172.16.113.0/24 > 172.16.110.254 - The tracert packet stops at this gateway 172.16.110.254.
Route in Firebox at site A:
172.16.110.0/24 > 172.16.111.254 - OK, bridge working.
Thank You.
Can the VPN client ping 172.16.111.254?
Add an Any packet filter on site B From: 172.16.113.0/24 to 172.16.111.0/24
Move this policy to the top of your policies list.
Turn on Logging on this policy.
Test access from the VPN client & see what shows up in site B Traffic Monitor
None of VPN client can reach with ping for 172.16.111.254 or 172.16.110.254. Ok, I will test this.
Thank You.
Hello Bruce,
The policy on site B didn’t work. However, the test with the VPN bridge mode was successful. To apply restrictions to VPN users, it was necessary to add the range in the policies and use the deny option.