VPN and Local Network Issue
cyberinv
Newbie ✭
We are having issues on implementation of our VPN with clients on the GVC software. We previously had a Watchguard device and while on full-tunnel clients were able to still use a USB adapter that had a virtual NIC to communicate between software on the client and devices connected to the adapter. 10.133.7.2 (virtual NIC) and 10.133.7.1 (USB adapter)
Since we have moved to the SonicWall NSa 4700 that communication is disrupted. It is only able to communicate while split-tunnel is set. Wireshark running on the client shows on full-tunnel the adapter and its virtual NIC are sending ARPs and responding with their MACs and nothing else. While on split-tunnel Wireshark is showing TCP and broadcast as it should between the two.
Ive tried every setting possible and cant get the local adapter to connect to its virtual NIC. IT almost feels like a step or quirk that exists on the Sonicwall that didnt exist on the WatchGuard. The watchguard was also using full-tunnel.
Ready to start banging head on wall.
Best Answers
-
CORRECT ANSWERArkwright
Community Legend ✭✭✭✭✭
No, that's at the firewall end. It's simply NATing all packets RFC1918 when going out of WAN, which is a reasonable thing to do.
Your issue is client-side.
0 -
CORRECT ANSWER
TKWITS
Community Legend ✭✭✭✭✭
" how do I bring that traffic back 'down' to the PC for the communication to continue functioning between that device and its software on the PC"
Use split tunneling
0
Answers
Sounds like you were taking advantage of a quirk in the Wachguard VPN stack which bound to one interface.
if GVPN functions as Netextender does
NetExtender also adds routes for the local networks of all connected Network Connections. These routes are configured with higher metrics than any existing routes to force traffic destined for the local network over the SSL VPN tunnel instead. For example, if a remote user is has the IP address 10.0.67.64 on the 10.0.*.* network, the route 10.0.0.0/255.255.0.0 is added to route traffic through the SSL VPN tunnel.
I was going to say the same thing. It sounds like you unintentionally found a quirk in the Watchguard VPN client, and things 'just worked' for you.
Since you are using tunnel-all, ANY IP traffic for ANY subnet will go over the tunnel. That's why its called tunnel-all, and thats why you are still seeing ethernet traffic in wireshark.
As hinted at, look at the routing table on the PC in both scenarios. If the tunnel route has precedence over the local route, than the traffic will go over the tunnel.
OK. Thank you both for the replies. That would make sense then the confusion on why this stopped working while using replicated settings from the old hardware. So Im not using the SSL VPN option, but am using IKE with Ipsec VPN. While on split and full tunnels the route tables in both scenarios are similar with the USB/Virtual NIC having a higher metric.
I guess my question is then - if Ive got this local network between the PC and the USB adapter for the software on the PC (10.133.7.2 < - > 10.133.7.1) how do I bring that traffic back 'down' to the PC for the communication to continue functioning between that device and its software on the PC. We did work with the vendor and tried adding routes on the PC itself, but that had no effect.
I did find this on the Watchguard:"192.168.0.0/16172.16.0.0/1210.0.0.0/8By default, the Firebox enables dynamic NAT for outbound traffic from addresses in these ranges to any external interface."Could this be why my local subnet was still working while using the full tunnel since it fell within that private range?You might be able to manually add a static route post-connection to override this - but if that was the case then I would have expected the connected route to take precedence anyway. Windows networking is not my strong suit!
Thank you all. I appreciate the feedback and expertise in narrowing it down to the client side!