ISP providing multiple public WAN IPs via DHCP. SonicWall TZ400 hates it.
RWilliams7
Newbie ✭
My ISP is giving me a block of 4 static IPs via DHCP based on the MAC address of my devices. The ISP calls them "semi-static". No matter how I try, only one interface can grab an IP. I imagine this is because SonicWalls hate to have more than one WAN-IP on the same subnet.
Some of my reading has suggested that I need to get a router to place in front of the SonicWall so that the public IPs do not appear to be on the same WAN.
Is there a solution that doesn't require more hardware? I would like to run 3 webservers from behind the SonicWall.
Category: Mid Range Firewalls
0
Answers
Forgot to say... Using static IPs that are actually static works flawlessly.
ISPs like this should not be allowed to run. If they are giving you static IPs than they cannot be handed out via DHCP.
If you have an IP that works when assigned statically, just use that one and read up on NAT.
See this post for an explanation.
Tried to be clear. I do not have static option and I've already read up on Nat. The ISP moved me away from true static IPs. The only IPs they are giving out with the fiber optic upgrade are via DHCP.
Also, I already read that same post. To be clear, there is no more static option. When I upgraded to fiber, they insisted that the only "static IPs" they offer are permanent DHCP reservations.
Due to monopoly issues with ISPs, they are the only fiberoptic game in town.
Hi @RWILLIAMS7,
We should be able to run the web servers on 3 different public IP's using the one to one NAT mapping method. Only one IP address from a subnet can be configured on the SonicWall directly and the rest available public IP's should be used virtually using NAT policy mappings. SonicWall would be able to understand the other available public IP addresses from the subnet mask defined on the WAN interface.
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
This is the strategy that I would like to see work. I'll describe this with BEFORE and AFTER to distinguish the environments.
BEFORE (CABLE INTERNET):
Static IPs provided by the ISP:
XXX.XXX.XXX.24
XXX.XXX.XXX.25
mask 255.255.255.0
Sonicwall is set static on XXX.XXX.XXX.24.
IPs are static from the ISP.
The wizard works perfectly forwarding XXX.XXX.XXX.24 and XXX.XXX.XXX.25 to internal IPs behind the firewall. This is what I think Saravanan is recommending, but it was what I was already doing with static IPs and Cable Internet. As you see below, it doesn't work in the new environment.
AFTER (FIBER-OPTIC):
DHCP used to deliver "semi-static IPs" to the SonicWall.
YYY.YYY.YYY.101 YYY.YYY.YYY.102 YYY.YYY.YYY.103 YYY.YYY.YYY.104
mask 255.255.254.0 (via DHCP. not set manually).
IPs are assigned via DHCP reservations using MAC addresses pre-shared with the ISP.
The first interface assigned to WAN can grab an IP via DHCP using its MAC address. The next interface will fail whether the assignment is manual or via DHCP because the SonicWall by design will not tolerate WAN IPs on the same subnet. This is the fundamental problem: Sonicwall vs. ISP.
So we try what worked for the static IPs. We don't have physical interface assigned to YYY.YYY.YYY.102. We just rely on the Sonicwall that has successfully grabbed YYY.YYY.YYY.101 to handle the traffic. We use the wizard to assign the web servers to YYY.YYY.YYY.102, YYY.YYY.YYY.103 and YYY.YYY.YYY.104. Does it work? No it does not. Traffic does not pass.
I imagine that this is because the ISP is not passing that traffic to YYY.YYY.YYY.101. The ISP's gateway believes that it knows the route to 102, 103, and 104. They haven't obtained their IP addresses by DHCP, so those packets go nowhere.
I have a NetGear router lying around. I can tell it to use one of the pre-shared MAC addresses and have it obtain an address via DHCP. Then I can connect the Web Server VM to the Netgear. This will at least prove that things work when the devices grab their IPs via DHCP. It will still leave me at the mercy of two companies with a different philosophy about WAN IP addresses.
I will post an update once that experiment is done.
To clarify, in the AFTER scenario above, the Web Server assigned to YYY.YYY.YYY.101 works as expected. The other Web Servers are the ones that fail. Only traffic that involved a physical interface with a WAN IP address goes through. Virtually using the public IPs does not work. My assumption is that the Wizard is doing this exactly as Saravanan has recommended. Sorry for not making that clear.
Hi @RWILLIAMS7,
Thanks for explaining the scenario. You did clarify well.
In this case, I would recommend you to setup a packet capture on the SonicWall as per below KB article. This can isolate the issue by tracing the packets at the SonicWall. If my guess is right, we may not see traffic destined for one of the useable IP's on the SonicWall for incoming traffic.
Let me know what happens.
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
When I use the Packet Monitor on the working IP address (YYY.YYY.YYY.101)with filters for ports 80 and 443. I can see plenty of traffic as I use my cell phone to connect to the web sites. The cell phone is using an external address, not connecting to WIFI.
When I do the same for the IP addresses that we suspect are being blocked, I see only a few entries under Ether Type: LLC (0x26), LLC (0x27), 0x8899 (dropped).
I do not see any of the normal looking traffic. for YYY.YYY.YYY.102.
Maybe I can beg the ISP for help. Of course, an override option for the SonicWall would be nice. Imaging a dialog box that says "I know it shouldn't be this way and my ISP is unreasonable" that allows the SonicWall to ignore the rule on WAN IPs on the same subnet.
Hi @RWILLIAMS7,
I would recommend you to perform the packet capture based on the source public IP address to filter the precise traffic.
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
You are correct by thinking you are not receiving the traffic for the other IPs due to them being complete idiots...sorry...the DHCP address not being assigned.
You might give them the same MAC address for all IPs and see how that goes, or have them create a route pointing all your other IPs to your x.x.x.101 working address. Unfortunately at this point your answer lies with the ISP and not with the Sonicwall.