08-20-2012 10:05 AM
We have a strange issue for one of our customers that recently migrated to our internet service.
They are trying to vpn to an external ip address not controlled by ourselves. The issue is only on one subnet and isolated to Mac’s, PCs in the same subnet also work fine. They were able to vpn from the MACs before they migrated to our INET solution. They previously used a checkpoint FW for their outside NAT and firewall and now are using a failover pair of asa 5510s. I have packet traced out the firewall and there should be nothing blocked. UDP ports 500 and 4500 are open to the destination ips from the correct subnets. All other subnets with Windows PCs can vpn out to external ip without issue. The users in that subnet with the MACs can also browse internet fine so the routing and nat overloading is also ok
When they try to initiate a connection from the macs i can see the connection/xlate coming in from a source port of udp 4500/500 and also a destination of udp 4500/500 instead of a random source port. Just this evening we managed to get one device connected but no others. Would the fact that the source port is claiming 500 and 4500 stop the other macs using the same source ports at the same time to connect out?
They are using the onboard mac vpn client, he can’t get the Cisco one working at the minute.
connections:
UDP OUTSIDE:external ip/4500 INSIDE:192.168.32.157/4500, mac connections
UDP OUTSIDE:external ip/4500 INSIDE:192.168.32.12/4500,
UDP OUTSIDE:external ip/4500 INSIDE:192.168.4.23/2672, pc connections
UDP OUTSIDE:external ip/4500 INSIDE:192.168.4.23/2672
UDP PAT from INSIDE:192.168.32.12/4500 to OUTSIDE:Outside Address/4500 flags ri idle 0:01:15 timeout 0:00:30
UDP PAT from INSIDE:192.168.32.12/500 to OUTSIDE:Outside Address/500 flags ri idle 0:01:15 timeout 0:00:30
Any help would be appreciated, bit of a strange one
08-20-2012 01:09 PM
Brian,
Most Cisco devices will want to do negotiation source and destined port of UDP/500 or UDP/4500.
It should not matter whethere there are multiple connections unless there something "smart" on the path.
On ASA we have this functionality:
http://www.cisco.com/en/US/docs/security/asa/asa84/command/reference/i2.html#wp1761012
You might want to check if it's enabled or disabled.
I'm not sure why only Mac clients would be affected, that's odd. Typically Cisco clients and Mas' built in client are behaving almost in the same way during negotiation.
I think it might make sense to have our TAC investiagte the firewall if you're out of ideas ;-)
M.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide