Internet drops when ing mac#

And, of course, part of NAT is that the interface must respond to ARP requests for addresses it's NAT'ing. You would have consumed a ton of valuable IP addresses for internal traffic management. Even medium sized businesses don't do this. So, mmm, ok, I'll need 30 interfaces on my firewall? What a mess. Your perimeter router interface IP would be say 75.51.206.2 and it would have a say 8 interfaces say 75.51.206.3 - 75.51.206.11 then you need a firewall and it has an interface.but wait, I want this firewall to expose 30 web servers to the internet from a DMZ, each with it's own IP. If you are using from this space for router interface IPs, then you might say 75.51.206.1 is your ISP's (next hop) interface. So, for example, let's say you have a /24 IP allocation. What I mean here is the IP address of the interfaces for the routers and other devices that participate in moving packets around are different than the IP addresses of the packets they are moving. In larger networks, the routing network is different than the routed network. Most people simply use the IP given to them by their ISP. In small, home office type networks you would be correct. The interfaces on the routers typically don't have IPs that are in the subnets of the traffic they route. Routing networks are commonly completely different than the traffic they route. The firewall drops the ARP request because it says that 75.51.206.55 is not on it network, but it has failed to consider the NAT policy that made all egress traffic from the interface look like it came from 75.51.206.55.

Internet drops when ing mac#

But, of course, in order for the router to send it out at the data access layer it needs to know the MAC address to send it to.which the firewall has failed to provide. Our router has a static route that sends it out a particular interface. The routing in the internet gets it to our perimeter router. Ok, when someone (host) replies to this packet it knows only to send it (destination) to 75.51.206.55. Remember, the firewall is replacing the source IP address of all egress packets with 75.51.206.55 so the whole world past the firewall's WAN interface believes this packet came from 75.51.206.55.that's the purpose of NAT. The firewall should respond with the MAC address of the firewall's WAN interface because this WAN interface is NAT'ing egress traffic to 75.51.206.55. So it needs to know the MAC address of 75.51.206.55 so it sends out an ARP expecting that someone in the broadcast domain of its interface knows the MAC address. It knows it needs to go out a certain interface (who's IP is 10.5.1.1).

The router has this packet with a destination IP of 75.51.206.55. The firewall's WAN interface is 10.5.1.2. This is very common in router configurations. This interface on the router has 10.5.1.1 as its IP address. The router routes 75.51.206.55 out a particular interface via a simple static route. It doesnвЂ™t seem to consider NAT policies !! Anyway, perhaps some sort of static route would work around the problem or some overriding security policy. ItвЂ™s probably as simple as the SonicWall has a (hard-coded) security policy that rejects ARP requests for hosts (75.51.206.55 in our case) that it thinks are not on itвЂ™s subset. SonicWall support has pretty much given up. I configured a Static ARP entry for 75.51.206.55 on the SonicWall and set it to publish.

That works for daysвЂ¦until the thread on the SonicWallвЂ™s OS dies or an HA failover happens. There is another setting in the internal settings page to repeated send gratuitous ARP responses every 60 minutes.

Then the router sends another ARP request for 75.51.206.55 and itвЂ™s dropped by the SonicWall. Hit that button and the router is happyвЂ¦until itвЂ™s cache times outвЂ¦about 4 hrs. There is an internal settings page (/settings/diag.html) on the SonicWall that has a button to send gratuitous ARPs. The router canвЂ™t get a MAC address for 75.51.206.55 so it canвЂ™t send traffic to the WAN interface on the SonicWall and our connectivity goes away. However, via packet capture on the SonicWall I notice that the router at 10.5.1.1 sends an ARP request to the SonicWall for 75.51.206.55 The SonicWall drops the ARP request. To the outside world, everyone on our LAN appears to be at 75.51.206.55. We have a single NAT policy that for the WAN interface that maps the source IP for all egress traffic on the WAN interface to 75.51.206.55. The WAN interface (X1) has IP address 10.5.1.2 Our internal routerвЂ™s interface is 10.5.1.1.

We have a pair of SonicWall 2700вЂ™s in a very simple HA configuration.