When the CPE is in NAT mode tracert from windows XP ‘times out’ on all hops except the final destination.
C:’>tracert 10.10.10.1
Tracing route to 10.10.10.1 over a maximum of 30 hops
1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 15 ms 14 ms 14 ms 10.10.10.1 – Destination
This is our network - the destination is 5 hops out… we don’t block tracert or ping …
Is this normal ?
thx
no this is not normal…
what your IP address and config ? what is the IP of your SM ? what is your setup (between machine and SM)
I would expect you to see atleast the first hop (SM ?)
The subnet is 10.30.100.0/24.
Backhual Radio (which is routed) is at 10.30.100.1/24
Backhual Radio has no routes for the CPE - it shouldn’t since the AP is bridging and the /24 covers the whole subnet
Backhual Radios PtP IP is 10.20.10.2- it’s peer is 10.20.10.1
AP IP 10.30.100.130/24 (we set it above the /25 mark for furture subnetting considerations)
AP Gateway IP 10.30.100.1
AP RF Private 172.16.128.1
CPE NAT Public Network Interface is 10.30.100.150/24
CPE Gateway IP address 10.30.100.1 (the backhual radio)
CPE Private Network Interface 192.168.11.1/24
CPE RF Public 172.16.128.131
DMZ Host is NOT enabled
The CPE can route to the Internet, and I can ping it’s public interface from the NOC. User can surf fine too. But tracert shows * * * on all but the final hop and a VPN Software that uses a UDP Wrapper for NAT Traversal fails when the CPE is in NAT mode. Works fine when the CPE is in “Transparent” mode.
I tried moving the Customer to the DMZ IP on the CPE - no change: trancert doesn’t work and the UDP wrapped VPN connection fails.
Changing the CPE to bridged (transparent) mode works perfectly (of course).
From what I’ve read in the forum history Jerry and others are deploying NAT routers (e.g. dlinks) at the customer site, and bridging the WAN side of the NAT router through the SM. Is this Why? The Moto UDP NAT engine just doesn’t work? That’s a real PITA.
Thx
So here is the tracert with the SM running a NAT
C:’>tracert -d 172.16.2.200
Tracing route to 172.16.2.200 over a maximum of 30 hops
1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 19 ms 14 ms 19 ms 172.16.2.200
Trace complete.
And the tracert with the SM bridging:
C:’>tracert -d 172.16.2.200
Tracing route to 172.16.2.200 over a maximum of 30 hops
1 12 ms 9 ms 9 ms 10.30.100.1
2 17 ms 9 ms 14 ms 10.30.20.1
3 16 ms 9 ms 14 ms 10.10.40.1
4 9 ms 14 ms 14 ms 10.10.20.1
5 17 ms 14 ms 14 ms 172.16.2.200
Trace complete.
So the hops are accurate, but the intermediate replies don’t show up ?
In this case the SM’s ‘public’ IP was 10.30.100.150… I captured the NAT Table below
NAT Table
Orig IP Port Final IP Port Prot ALG Status HFin RFin Timeout
192.168.011.100 4928 010.030.100.150 12037 UDP - 1 - - 4
192.168.011.100 4927 010.030.100.150 12038 UDP - 1 - - 4
192.168.011.100 4925 010.030.100.150 12039 UDP - 1 - - 4
192.168.011.100 4924 010.030.100.150 12040 UDP - 1 - - 4
192.168.011.100 4923 010.030.100.150 12041 UDP - 1 - - 4
192.168.011.100 512 010.030.100.150 12042 ICMP - 1 - - 2
192.168.011.100 4911 010.030.100.150 12043 TCP - 1 - - 120
192.168.011.100 4909 010.030.100.150 12044 TCP - 1 - - 119
192.168.011.100 3920 010.030.100.150 12045 UDP - 1 - - 4
192.168.011.100 4907 010.030.100.150 12046 UDP - 1 - - 3
192.168.011.100 4906 010.030.100.150 12047 UDP - 1 - - 3
192.168.011.100 4905 010.030.100.150 12048 UDP - 1 - - 3
192.168.011.100 4904 010.030.100.150 12049 UDP - 1 - - 3
192.168.011.100 4902 010.030.100.150 12050 UDP - 1 - - 3
192.168.011.100 4903 010.030.100.150 12051 UDP - 1 - - 3
192.168.011.100 4900 010.030.100.150 12052 UDP - 1 - - 3
192.168.011.100 4901 010.030.100.150 12053 UDP - 1 - - 3
192.168.011.100 4899 010.030.100.150 12054 UDP - 1 - - 3
192.168.011.100 4898 010.030.100.150 12055 UDP - 1 - - 3
used 19 free 2029
Does this make any sense to anyone ?