SonicWALL TZ 215 - Configuring second public IP address from different subnet
InTech97
Newbie ✭
The data center where my TZ 215 firewall and physical server is colocated is issuing me a new public IP address scheme. The data center will temporarily configure their equipment to route both the old, existing IP address scheme and the new IP address scheme to my firewall to ensure uninterrupted, simultaneous access to services during the transition effort. Windstream owned the old IP address scheme and has requested that the data center return the IP addresses. Consequently, the data center is issuing new IP addresses to me that the data center owns.
Both the old and new IP address schemes provide me with three (3) client usable IP addresses. The IP address schemes are completely different such that the old, client usable IP addresses are (for example) 1.1.150.226 - .228 and the new client usable IP addresses are 2.2.9.220 - .222. Subnet / CIDR masks are: OLD 1.1.150.224/29, NEW 2.2.9.216/29. Netmasks for both schemes are 255.255.255.248. I can provide further details on network, default gateway, routers and broadcast IP addresses if needed. In the examples above, the first two octets are fictitious (i.e. OLD 1.1.x.x and NEW 2.2.x.x) but the second two octets are the actual values (i.e. OLD x.x.150.226, NEW x.x.9.220).
The TZ 215 is currently configured for the old IP address scheme (i.e. 1.1.150.x) and is working fine. I can manage the firewall and users can access services behind the firewall through various NAT policies and Access rules that someone else configured years ago.
My conundrum is that I need to be able to manage the firewall and access all services behind the firewall using both IP address schemes simultaneously. However, I'm somewhat stumped as firewall configuration is a bit out of my wheelhouse.
Does the TZ 215 even support this simultaneous access? I've scoured the Internet and found all kinds of instructions related to newer SonicWALL firewall appliances but nothing seems to apply to the TZ 215.
My first effort, which failed, was to see if I could manage the firewall from both IP address schemes. I created a static ARP entry for the new IP linked to the X1 interface. However, I see lots of notes online that indicate that the SonicWALL firewall will not respond to HTTPS Management traffic over static ARP. I've tried various combinations of static ARP entries, NAT rules, Access rules but nothing works. Clearly, I am over my head and need guidance ... or it's true that the TZ 215 will not respond to HTTPS Management traffic over static ARP.
From what I've gleaned thus far, I need to create an Address Object for the new IP address, a NAT policy, and an Access rule. However, I still cannot get a response from the TZ 215 for HTTPS Management traffic using the new IP address of 2.2.9.220. Is it true that the TZ 215 will not respond to HTTPS Management traffic over static ARP?
My second effort (not yet pursued due to my newbie status on firewall configuration) would be to gain access to a web application hosted on a virtual server behind the firewall with one of the new public IP addresses (i.e. 2.2.9.221). What kinds of records do I need to create on the TZ 215 to get this to work?
As a first step, I have already modified the DNS entry at my domain name provider to map the web application of interest to public IP 2.2.9.221 setting the lowest TTL possible. After a few minutes, the ping of that web application confirmed that my local DNS cache contains the new IP address (2.2.9.221) for the web application of interest even though the ping request times out. So, the second effort would look something like this from a request standpoint:
NOTE: The web application of interest was accessible from the old public IP address prior to changing its DNS entry.
- DNS entry for web application changed to 2.2.9.221 (DONE)
- Incoming request for https resource on 2.2.9.221 (e.g. https://mywebapp.yadda.com)
- The virtual NIC on the Virtual server hosting the web application is only configured with a static private IP address of 192.168.2.21 and probably should stay that way. Consequently (and here's where my knowledge is sketchy), I assume I need a NAT policy record, among other things, to get from public 2.2.9.221 to private 192.168.2.21 where the only allowed services on that NAT policy record are http and https?
So for the second effort described above, what exactly are all the records/objects/things I need to configure on the TZ 215 to get this to work?
Any guidance would be greatly appreciated..
Best Answer
-
CORRECT ANSWERInTech97
Newbie ✭
I finally was able to convene a video conference with one of the network technicians at the data center. During our discussion, he created static ARP entries on the data center's routers to route traffic for the new IP addresses explicitly to the MAC address of the WAN interface of my client's SonicWALL firewall appliance.
This solved my issues.
Thank you to everyone who provided insight and useful suggestions to my initial query.
Cheers!
0
Answers
Can you configure your new network on a second WAN interface and have the DC remote hands plug that in for you?
Sonicwall does not support alias IPs either at all or in any straightforward way, so this is probably going to be your best approach long-term.
"Is it true that the TZ 215 will not respond to HTTPS Management traffic over static ARP?"
True, Sonicwalls will not do that no matter what the model or firmware.
As Arkwright suggested, getting another WAN interface connected would be the most solid and, considering your experience, least stressful for you. Otherwise you will be risking losing access completely.
But you are on the right track. Not only will you have to address your NAT policies, but also, eventually, your WAN interface IP.
That said asking a forum to do your work for you is a bit much. Come back with more steps to your plan and we can guide you.
Multiple IP ranges work fine for Inbound and Outbound
Configuring Multiple WAN subnets using static ARP with SonicOS Enhanced | SonicWall
The ISP's upstream router needs to be configured to forward this address range directly to your X1 Primary IP WAN address
Create WAN address objects for your new host IP on that WAN subnet and use them in your configuration
ARKWRIGHT: Thank you for the suggestions about using a second WAN interface. I will check with the network techs at the DC to see if this is an option. Regarding long-term approaches, the situation where both IP address ranges will be routed to my firewall is a purely temporary situation i.e. the OLD IP address range will be going away on 12/20/2024 leaving me with only the new IP address range. The trick is getting both IP address ranges to work within the TZ 215 configuration between now and 12/20/2024 to, as the DC said, "ensure uninterrupted access to services during the transition".
TKWITS: Thank you for the confirmation on Sonicwall devices not responding to HTTPS Management traffic over ARP. Regarding the latter portion of your reply, it was certainly not my intention to ask anyone to do my work for me. Respectfully, I don't think that is what I articulated in my original post. I freely confess that configuring firewall devices for routing and access rules, et al. in this specific use case is a bit out of my wheelhouse, but I've been a successful IT consultant for the better part of three decades working in many facets of the industry (software, hardware, basic networking, server administration, etc.) and I am confident that I am fully capable of understanding and executing on this effort with a nudge and some guidance. A man has to start somewhere, yes? It's hard enough for an industry veteran like me to admit defeat and ask for help. I had hoped that the Sonicwall community would be a welcoming environment and thought it would be an appropriate place to start. I'm confident that it still is. 🙂
MARKD: Thank you for your reply and the link to the configuration example that appears to be quite similar to my use case. I will definitely dig into that link. Can you direct me to any other resources that might further my education on firewall routing configuration in general i.e. a detailed explanation of what kinds of entries need to be in place in order for proper routing to occur?
UPDATE 10/23/2024: I started over and removed all of the configuration objects that I had put in place for the first (failed) experiment to gain HTTPS Management access over both IP addresses.
For the second effort to attempt to access a test web application using the new IP address, I added a static ARP entry for the new IP address on the X1 WAN interface along with some NAT Policies and Access Rules. Through trial and error (and lots of packet monitoring), I got it working to where I could access the web application using the new IP address. I configured the packet monitor to filter only for the source IP address requests coming from my laptop and the new destination IP address. The captured packets eventually showed as being FORWARDED and, at that point, accessing the test web application from my laptop was successful. I thought I had died and gone to heaven! However, my reverie was cut short when I got up the next morning and it was no longer working. I had not touched a thing and no one else has access to anything in my environment, so no one modified the firewall configuration without my knowledge. I contacted the DC to see if they had changed anything on their end and their preliminary reply (i.e. not comprehensive and all-to-brief over email) claimed that nothing had changed on their end. I will pursue this further with the DC to have a live discussion and get absolute confirmation that nothing changed on their end. Given my novice status at firewall configuration, I found this extremely confusing … and admittedly frustrating. If the DC is making fundamental changes without informing me, then they're certainly not doing this novice any favors. If the DC truly did not change anything on their end, how could the routing work one day and then not work the next day when no changes on the DNS A record nor the firewall device occurred? Has anyone ever experienced something similar and, if so, what was the root cause?
My short retort was against this line and wasn't meant to be malicious, just a reality check: "what exactly are all the records/objects/things I need to configure on the TZ 215 to get this to work?" Thats a vague and open-ended question. Frequent forum users will know I am blunt, but I genuinely try to help guide people. I don't believe providing all the answers will get anyone to learn, because learning gets everyone to a better understanding of what they are dealing with.
Anyways.
Did you include the route entry for the secondary subnet you have ARPd?
One thing about Sonicwalls is they REALLY like to have interfaces on the subnets they 'serve'. Static ARPs and associated routes do work, but in your situation thats the first half of the battle. You'll have to plan out converting those and more to actual interface, policy, etc. changes.
"how could the routing work one day and then not work the next day when no changes on the DNS A record nor the firewall device occurred?"
Its possible the ISP is expecting to route traffic for your new subnet to an IP address, rather than just out a physical port. If they can prove they are passing the appropriate traffic to your device (with a packet capture) than the answer is 'because Sonicwall'. Run your own packet capture to see what the Sonicwall is doing with the traffic.
This cannot not be an option. The only "optional" bit about it will be if they'll let you use two ports at once or not.