HP ProCurve 5406zl routing problem
HP ProCurve 5406zl routing problem
(OP)
I'm having some problem with routing an incoming connection - and I am no network engineer.
We got a new ISP with ethernet handoff through a WatchGuard - I do not have access to the WatchGuard. It is configured to NAT some of our public IPs to their corresponding internal server IPs, and put that traffic onto our switch on port A1.
I am unable to ping or connect to our servers using the new IP addresses assigned to us. It appears that it is routed correctly to us and our switch - but once at the switch it never reaches our servers.
Here is our setup.
We have 10 VLANs, and I believe our core switch (the 5046zl) is doing the routing between the subnets/VLANs. This core switch is connected to two other switches: a 2650, and a 2626 - I believe using some sort of Trunk. Our servers are attached to these last two switches and are in the IP subnet: 192.168.107.0/24. "show ip route" on the 5406zl shows that destination should be routed to our DMZ VLAN.
I setup a laptop with Wireshark, and configured the switch for port monitoring, then pinged one of our new public IPs. Sorting through the Wireshark data, I did find the ICMP packets coming into the switch properly NATted to the servers IP address. These were apparently being routed to a MAC address that after some digging and using walkmib on the core switch maps to the following ifPhysAddress: 291, 292, 410-417, 429, and 430. I'm not really certain how to interpret that.
I hoping someone can help me debug what is going wrong and how to fix this.
Thanks.
We got a new ISP with ethernet handoff through a WatchGuard - I do not have access to the WatchGuard. It is configured to NAT some of our public IPs to their corresponding internal server IPs, and put that traffic onto our switch on port A1.
I am unable to ping or connect to our servers using the new IP addresses assigned to us. It appears that it is routed correctly to us and our switch - but once at the switch it never reaches our servers.
Here is our setup.
We have 10 VLANs, and I believe our core switch (the 5046zl) is doing the routing between the subnets/VLANs. This core switch is connected to two other switches: a 2650, and a 2626 - I believe using some sort of Trunk. Our servers are attached to these last two switches and are in the IP subnet: 192.168.107.0/24. "show ip route" on the 5406zl shows that destination should be routed to our DMZ VLAN.
I setup a laptop with Wireshark, and configured the switch for port monitoring, then pinged one of our new public IPs. Sorting through the Wireshark data, I did find the ICMP packets coming into the switch properly NATted to the servers IP address. These were apparently being routed to a MAC address that after some digging and using walkmib on the core switch maps to the following ifPhysAddress: 291, 292, 410-417, 429, and 430. I'm not really certain how to interpret that.
I hoping someone can help me debug what is going wrong and how to fix this.
Thanks.
RE: HP ProCurve 5406zl routing problem
RE: HP ProCurve 5406zl routing problem
Running the port monitoring on the server port, I was able to detect the ICMP reply and response from the server. While my ping was failing this indicated that the incoming routes were indeed setup correctly, and that the server was attempting to respond.
Analyzing the Wireshark data for the ICMP response, I found that the response was using our old ISP still. After trying to fix the outgoing routes within the switch (with no success), I found that the default gateway of the servers was pointing to the old router, bypassing the outgoing routes I setup in the switch.
Once I changed the default gateway of the server to point to the core switch, my outbound routes started working - and so did my ping.
RE: HP ProCurve 5406zl routing problem
I've forgotten where you can check how these are mapped but there will be various show commands that elucidate it for you: try "show interfaces" for starters.
RE: HP ProCurve 5406zl routing problem
Fortunately for my issue it no longer matters, as we up and running on the new ISP - and everything appears to be working correctly. Now we just have to wait for DNS to fully propagate.