davidmccarthy
asked on
UDP 5440 not connecting between two Lan-to-Lan VPN's on a Cisco VPN 3000
I have a WAN with three locations. HQ, Dallas, and Boston. There is a VPN 3005 in HQ the connects the two other locations. Dallas has a ASA and Boston has a PIX, both connected using IPSec back to HQ.
I also have a VOIP system in all three locations. HQ can connect to both remote locations, but the VOIP system in Dallas cannot connect to the VOIP system in Boston. It uses UDP 5440. The two remote offices can ping eachother and other TCP communication works.
As far as I can tell, I have no filters or access control lists that would be blocking this. Any ideas?
I also have a VOIP system in all three locations. HQ can connect to both remote locations, but the VOIP system in Dallas cannot connect to the VOIP system in Boston. It uses UDP 5440. The two remote offices can ping eachother and other TCP communication works.
As far as I can tell, I have no filters or access control lists that would be blocking this. Any ideas?
ASKER
kyleb84: I don't think that's my problem. Here's more detail:
HQ is 10.0.0.0/16
Dallas is 10.8.0.0/16
Boston is 10.7.0.0/16
In the Boston PIX, the tunnel is setup with:
access-list TunnelToHQ permit ip 10.7.0.0 255.255.0.0 10.0.0.0 255.255.0.0
access-list TunnelToHQ permit ip 10.7.0.0 255.255.0.0 10.8.0.0 255.255.0.0
Likewise the Dallas ASA has:
object-group network HQ
network-object 10.0.0.0 255.255.0.0
network-object 10.7.0.0 255.255.0.0
access-list outside_20_cryptomap extended permit ip 10.8.0.0 255.255.0.0 object-group HQ
access-list inside_nat0_outbound extended permit ip 10.8.0.0 255.255.0.0 object-group HQ
I'm leaving out a bunch of stuff here, but it's because I don't think it is relevant. The UDP traffic I'm having trouble with flows fine between both remote offices and HQ.
I think the problem must be some combination of the VPN 3005 in HQ and/or the core router in HQ.
There are no access-list at all on the core router (10.0.0.1) It has the following routing table:
0.0.0.0 0.0.0.0 <internet firewall>
10.0.0.0 255.255.0.0 <connected>
10.8.0.0 255.255.0.0 <vpn 3005>
10.7.0.0 255.255.0.0 <vpn 3005>
It might be impossible to list all of the configuration of the VPN3005 since it is mostly web-based, but neither Lan-to-Lan tunnel has a filter on it. The tunnel default gateway is 10.0.0.1.
When I traceroute from Dallas to Boston (because ICMP does work), it goes to the Dallas ASA -> Core Router -> VPN 3005 > Boston
As far as I know routing is the same for TCP and UDP, but maybe my routing scheme is affecting the UDP packets?
HQ is 10.0.0.0/16
Dallas is 10.8.0.0/16
Boston is 10.7.0.0/16
In the Boston PIX, the tunnel is setup with:
access-list TunnelToHQ permit ip 10.7.0.0 255.255.0.0 10.0.0.0 255.255.0.0
access-list TunnelToHQ permit ip 10.7.0.0 255.255.0.0 10.8.0.0 255.255.0.0
Likewise the Dallas ASA has:
object-group network HQ
network-object 10.0.0.0 255.255.0.0
network-object 10.7.0.0 255.255.0.0
access-list outside_20_cryptomap extended permit ip 10.8.0.0 255.255.0.0 object-group HQ
access-list inside_nat0_outbound extended permit ip 10.8.0.0 255.255.0.0 object-group HQ
I'm leaving out a bunch of stuff here, but it's because I don't think it is relevant. The UDP traffic I'm having trouble with flows fine between both remote offices and HQ.
I think the problem must be some combination of the VPN 3005 in HQ and/or the core router in HQ.
There are no access-list at all on the core router (10.0.0.1) It has the following routing table:
0.0.0.0 0.0.0.0 <internet firewall>
10.0.0.0 255.255.0.0 <connected>
10.8.0.0 255.255.0.0 <vpn 3005>
10.7.0.0 255.255.0.0 <vpn 3005>
It might be impossible to list all of the configuration of the VPN3005 since it is mostly web-based, but neither Lan-to-Lan tunnel has a filter on it. The tunnel default gateway is 10.0.0.1.
When I traceroute from Dallas to Boston (because ICMP does work), it goes to the Dallas ASA -> Core Router -> VPN 3005 > Boston
As far as I know routing is the same for TCP and UDP, but maybe my routing scheme is affecting the UDP packets?
""As far as I know routing is the same for TCP and UDP, but maybe my routing scheme is affecting the UDP packets?""
I don't see how... routing only happens at layer 3 - IP, not layer 4 - TCP/UDP.
What you've described is exactly how it should be set up, and your ICMP pings proves that the routing is properly configured.
--------------------------
You say it's the VoIP system that need to communicate via UDP... I'm guessing your tests were made on a PC?
How is the routing table set up on those VoIP systems?
I don't see how... routing only happens at layer 3 - IP, not layer 4 - TCP/UDP.
What you've described is exactly how it should be set up, and your ICMP pings proves that the routing is properly configured.
--------------------------
You say it's the VoIP system that need to communicate via UDP... I'm guessing your tests were made on a PC?
How is the routing table set up on those VoIP systems?
ASKER
I'm using Shoretel VOIP switches. Here's the routing table from Boston:
destination gateway
------------- -----------
0.0.0.0 10.7.0.1
10.7.0.0 10.7.0.5
10.7.0.1 is the PIX in Boston and 10.7.0.5 is the VOIP box.
When I telnet into VOIP box I can run a standard ping to the Dallas VOIP just fine. When I run what Shoretel calls a "lsp_ping", it fails. According to their tech support, the lsp_ping is trying to communicate using UDP 5440. So of course, they are claiming that something must be blocking it along way.
I suppose another approach would be to eliminate the VOIP all together and prove that I can get UDP 5440 from one location to the other. I know how to test TCP stuff, like telneting to a specific port on a server to see if it connects. How can I simulate something like that with UDP?
destination gateway
------------- -----------
0.0.0.0 10.7.0.1
10.7.0.0 10.7.0.5
10.7.0.1 is the PIX in Boston and 10.7.0.5 is the VOIP box.
When I telnet into VOIP box I can run a standard ping to the Dallas VOIP just fine. When I run what Shoretel calls a "lsp_ping", it fails. According to their tech support, the lsp_ping is trying to communicate using UDP 5440. So of course, they are claiming that something must be blocking it along way.
I suppose another approach would be to eliminate the VOIP all together and prove that I can get UDP 5440 from one location to the other. I know how to test TCP stuff, like telneting to a specific port on a server to see if it connects. How can I simulate something like that with UDP?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Well I guess it wouldn't be your laptop, since you'd be at HQ, but anyway, you get the point.
Dude. I'm having this issue and it's driving me mad!
How did you fix it?
How did you fix it?
But, where is teh answer?
Have a look at the configs and see if there's something like a::
access-list permit 101 tcp (...)
but no:
access-list permit 101 udp (....)
If so, change it to:
access-list permit 101 ip (...)
That'll allow TCP + UDP.
Maybe post your configs if you still can't figure it out?
Be sure to remove all usernames/passwords first!