Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

Vpn issue mac issue

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.


UDP OUTSIDE:external ip/4500 INSIDE:, mac connections

UDP OUTSIDE:external ip/4500 INSIDE:,

UDP OUTSIDE:external ip/4500 INSIDE:, pc connections

UDP OUTSIDE:external ip/4500 INSIDE:

UDP PAT from INSIDE: to OUTSIDE:Outside Address/4500 flags ri idle 0:01:15 timeout 0:00:30

UDP PAT from INSIDE: 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

Cisco Employee

Vpn issue mac issue


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:

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 ;-)


CreatePlease to create content