I work for a wireless ISP and all we use is Motorola Canopy. We have been turning NAT on all of our connections and it seems like now all of a sudden we are haveing issues with customers being unable to connect to their VPN’s. We’ve been doing some TCP dumps to see what we can come up with. I changed our information to us
NAT and DMZ:
14:51:50.709559 us.1047 > ck.vpn.att.com.500: isakmp: phase 2/others I inf[E]: [encrypted hash]
14:51:50.766926 us > ck.vpn.att.com: icmp: 169.254.1.2 udp port 1047 unreachable
14:51:50.790533 us > ck.vpn.att.com: icmp: 169.254.1.2 udp port 1047 unreachable
NAT but NO DMZ:
14:57:03.870383 us.1028 > al.vpn.att.com.500: isakmp: phase 2/others I inf[E]: [encrypted hash]
14:57:03.930518 us > al.vpn.att.com: icmp: 169.254.1.2 udp port 1028 unreachable
14:57:03.970261 us > al.vpn.att.com: icmp: 169.254.1.2 udp port 1028 unreachable
With NAT off everything works like a charm…any ideas? or any hints as to what else we should look into?
Thanks,
Jeff
By default a standard IPSec virtual private network (VPN) tunnel would not work if there were one or more NAT or PAT points in the delivery path of the IPSec packet. This feature makes NAT IPSec-aware, thereby, allowing remote access users to build IPSec tunnels to home gateways.
Problem: Identification IKE payload contains embedded IP addresses.
Solution: By sending the original address in the NAT-OA IKE payload, a recipient has the original address with which to verify the contents of the Identification IKE payload during Quick Mode negotiation. Because the NAT-OA IKE payload is not sent until Quick Mode negotiation occurs, IPSec implementations that validate the IP address in the Identification IKE payload that is sent during Main Mode must either not perform this validation or validate the peer by using another mechanism, such as name verification.
IPSec NAT Traverael or IPSec NAT-T-capable peers during the IPSec negotiation process will automatically determine:
• Whether both the initiating IPSec peer (typically a client computer) and responding IPSec peer (typically a server) can perform IPSec NAT-T.
• If there are any NATs in the path between them.
If both of these conditions are true, the peers automatically use IPSec NAT-T to send IPSec-protected traffic across a NAT. If either peer does not support IPSec NAT-T, then normal IPSec negotiations (beyond the first two messages) and IPSec protection is performed. If both peers support IPSec NAT-T and there are no NATs between them, normal IPSec protection is performed.
I have not tried the NAT on the Canopy devices, but would assume that their software does not ahve the NAT-T capability.
I hope that helpsyou understand what is going on.
Cian
카지노사이트 | 2020 NICE 바카라사이트The year of the event was over, and the year of hope and dream came to an end. Don't let bygones be bygones and lose all your energy in the coming days.