Forcing traffic destined from the inside to one WAN interface out the other
xdmfanboy
Newbie ✭
I have an odd customer requirement, which I won't try to explain, but the bottom line is I need hosts on a public network hanging off a DMZ to got out one WAN port (X2) and SSLVPN to another WAN port (X1), both obviously on different Internet links. The return traffic would have to reverse the path. Through static routing I do force all the public traffic out X2, and all corporate out X1, no luck. Is this even possible, or is the Sonicwall going to see source and destinations are internal and refuse to loop it outside?
Category: Mid Range Firewalls
0
Best Answer
-
CORRECT ANSWER
TKWITS
Community Legend ✭✭✭✭✭
You don't need two SSLVPN profiles, you just need proper DNS records to handle internal and external requests for the same FQDN.
0
Answers
For clarity sake is below the ideal traffic flow?
Client SSLVPN -> Sonicwall DMZ interface -> Sonicwall WAN X2 -> ISP 2 -> INTERNET -> ISP 1 -> Sonicwall WAN X1 -> SSLVPN Internal LAN Access
The less details you give the less likely you'll receive help. But this complete flow is unlikely because of the internal routing table of the Sonicwall (as you have surmised).
What is possible is enabling SSLVPN on the DMZ zone; see the below KB.
Yes, that is the traffic flow. I can ping from DMZ to ISP 1 default gateway, but as far as I can go. ISP 1 can ping to X1 (this is all set up on a test bed with an L3 switch acting as ISP 1 & 2).
Customer insists his users are too stupid to handle two VPN connection profiles, one for use on the public side, and another for off-premise. I said even if they can't keep them straight, if one doesn't work try the other! He just won't do that,
Anyhow, replacing a 2650 with a 3700. On the 2650, years ago put an old trade-in TZ 215 in bridge mode to handle this problem, routing SSLVPN to a common switch connection outside the 2650 it could hit the WAN & Internet through, DHCP forwarded throguh the 2650 DMZ to Windows DHCP (wants the manageability of that vs. SW's DHCP). The TZ 215 is a performance bottleneck now (and ancient), and he wants it gone, not just replaced with a faster unit. I told him that was very unlikely given his constraints.
From a sanity standpoint: you can say no to peoples requests.
"You don't need two SSLVPN profiles, you just need proper DNS records to handle internal and external requests for the same FQDN."
Yes, thought of that. All public users are pointed to public DNS servers, so not sure how the distinction would be made. Only way I could see is if public users hit an internal DNS server, whereas when their staff hit public DNS when off premise. Maybe I could yet persuade him of that. He could have one and only one of his internal DNS exposed to the DMZ just for DNS.
"From a sanity standpoint: you can say no to peoples requests.." Yeah, he's been a client for over twenty years, my oldest client, so loathe to say no.
Why bother exposing an internal DNS server? Doesn't this company have a web presence (public website, public registrar, etc.)?
Not sure if I'm missing something. To avoid two connection profiles you'd have to use the same FQDN. How would one common public DNS server know to or be able to give two different responses to a DNS query depending on where they're coming from?
BTW, I did wind up queryng SW support, and they said no dice on doing any kind of loopback like I proposed with SSLVPN.
Example
FQDN: vpn.whatever.com
Internal DNS server would require whatever.com as a controlled zone, and a 'vpn' A record to point to the internal IP address of the interface on the Sonicwall that would be connected to (e.g. LAN 192.168.200.1).
External DNS server that controls the public whatever.com zone requires a 'vpn' A record to point to the external IP address of the interface on the Sonicwall that would be connected (e.g. WAN 23.45.67.89).
Internal PCs would query the internal DNS server for vpn.whatever.com and receive 192.168.200.1.
External PCs would query any public DNS server for vpn.whatever.com and receive 23.45.67.89.