5

We have a Sonicwall NSA 2400 that has been in service for some years now. We've never had an issue with any routing until we "upgraded" to a new NSA 2600 device. Below is a rough idea of the configuration:

NSA 2600 interfaces:

x0 - LAN IP x.x.10.223  x1 - WAN ISP #1   x2 - WAN ISP #2    x3 - WAN ISP #3 and x4 - LAN IP y.y.16.10

x0 and x4 are plugged into an HP Procurve 2920-48G-PoE+ switch and the server is on another HP Procurve 2920-24G switch plugged directly into the other.

The main server we are seeing routing issues with is an IBM AS400 with multiple IPs configured through virtual interfaces on its NIC. The IP addresses are on the LAN segments and are as follows:

x.x.10.4   x.x.10.6   y.y.16.22

This configuration was setup by a vendor for the AS400 and the y.y.16.0 subnet is for replication to be routed out of the x2 ISP #2 interface

The behavior we are seeing has stumped Dell/Sonicwall engineers and so I will describe it as best as I can here.

Upon plugging in all the interfaces, the ARP table starts filling up with the devices on the LAN segments. y.y.16.22, x.x.10.4 and x.x.10.6 do not show up. We have tried adding static ARP entries for them and the pings perform abnormally in that they will respond for a period of time then start dropping off one IP at a time.

Now if we leave the x4 (second LAN interface) unplugged then the x.x.10.4 and x.x.10.6 will appear in the ARP entries initially. We have run packet captures and find that ping requests from the Sonicwall NSA 2600 are 'generated' then 'consumed' but sometimes not forwarded.

We have cleared the ARP cache on the AS400, this is the second NSA 2600 device as the first was RMA'ed after being factory reset 3 times and even testing the settings imported from the 2400. We also tried setting the interface MAC addresses on the NSA 2600 to the same as the 2400. Oh, and we started this ordeal with Dell Powerconnect switches and were told they were an issue (by Sonicwall) so we bought HPs :-)

Any thoughts, advice or even a direction to look into would be appreciated as we have beat our heads on keyboards for a while, and spent hours on the phone with Dell/Sonicwall "support".

Thanks.

EDIT for RON:

1) correct. with static ARP entries it may ping for a few minutes then drop completely from the firewall but from other PCs on the network it still responds.

2) on packet captures for the NSA 2400 (old device) the ping trace from the firewall to AS400 goes 1-packet Generated by source 2-packet Consumed (by firewall) 3-packet Forwarded to AS400 so in the packet capture on the 2600 it is not forwarding the packets on the NSA 2600.

3) The AS400 has a single NIC with virtual interfaces configured so it is technically a single interface. Other machines on the network can ping the AS400 directly on the x.x.10.0 network and I've added the y.y.16.0 network to a machine and the pings never drop to any of those addresses. This issue seems to only be with the NSA 2600 device, which we've replaced...

Thanks Ron.

EDIT # 2: Packet captures show that ARP packets are going out but responses are not received when the x4 interface is plugged in. If the x4 interface is unplugged, the ARP responses are received. Same goes for unplugging the x0 interface for the x4 subnet.

EDIT # 3: Found out the AS400 is using what is called a Proxy ARP configuration. The physical NIC is used as a console for the system and also acts as a proxy for the virtual interfaces configured inside the AS400. The proxy responds to all ARP requests with the physical MAC address and then handles routing internally to the virtual interfaces. I've attached a drawing to clarify the setup as follows.

Still no headway on what is causing this behavior.

enter image description here

  • Youhave a lot of information here so let me ask a few clarifying questions: 1. the AS400 does not respond to pings unless you have static ARP entries, and then only sporadically? 2. What do you mean by 'consumed but not forwarded'? 3. If only one interface on the AS400 is connected, is it pingable? – Ron Trunk Jan 29 '14 at 1:48
  • See the Edit above. Too much to type in a comment. Thanks for looking at this. – Mike Naylor Jan 29 '14 at 2:09
  • so the virtual interface on the AS400 is a trunk that uses vlans to separate the networks, or something different? – Ron Trunk Jan 29 '14 at 3:46
  • Ron, the AS400 doesn't support vLAN tagging. It's a specialized IBM server and from what I've read has no vLAN support at all. Since it's on the same interface we can't really segment the traffic from the different subnets. I already mentioned taking the different subnet off the AS400 and putting it on another interface so we can vLAN the replication traffic but the argument was made that it works with the old firewall, which is a valid point. I'm not an AS400 guru so I'm not sure what else we could do on that end other than separate the networks, and I don't know how much trouble that is. – Mike Naylor Jan 29 '14 at 11:43
  • 1
    Alright, so after a LOT of testing today I've found that as soon as there is a physical route between x0 and x4... even with a vLAN to segment traffic, the ARP failure occurs. Also, if a host pings the firewall, the firewall can then see that host but if the firewall initiates ARP it fails as long as there is a physical path between the two LAN interfaces... I believe this is a bug in the firmware or a poor implementation of Spanning Tree on the 2600 that somehow crosses vLANs. – Mike Naylor Jan 29 '14 at 21:39
3

fter a long series of testing and support calls, Sonicwall produced a 'hotfixed' firmware that seems to fix this issue by adding a check box in the interface configuration to allow duplicate MAC addresses for devices that have multiple IP addresses on a single interface. So far this has proved to resolve the issue.

Hotfix # 142099

No word yet on if this will be released into the next production firmware but the tracking ID for this is the same as the hotfix # and should be referenced in release notes.

I had previously answered this but the answer was deleted...

protected by Community Mar 19 '14 at 15:40

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.