Re: Routing and Remote Access NAT - I need to modify TTL

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

"George Valkov" <a@xxxxx> wrote in message news:Ohj14nS4JHA.4632@xxxxxxxxxxxxxxxxxxxxxxx

"Ace Fekay [Microsoft Certified Trainer]" <aceman@xxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:%23Dt0OGN4JHA.4632@xxxxxxxxxxxxxxxxxxxxxxx
"George Valkov" <a@xxxxx> wrote in message
news:eOb3XSK4JHA.1808@xxxxxxxxxxxxxxxxxxxxxxx
Today I made a few tests to improve my skills with RRAS. NAT SERVER is
Windows 2003 ent, with two interfaces: PUBLIC (internet) and PRIVATE
(LAN).
Hosts on the LAN successfully acquire IP addresses from the NAT SERVER and
use it as a gateway, they can access hosts on the PUBLIC interface, TTL is
reduced by one.

Unfortunately my ISP has somehow made their gateway to always return
packets
with TTL=0. So while the server can access the ISP's gateway and the
internet, if a host (a virtual PC on the LAN side) wants to access the
internet, the
packet will reach it's target, but the replay that comes back to the NAT
SERVER
is with TTL=0, and the packet gets discarded just before arriving at the
client.

I know that TTL=0 can be cured under Linux with IPTABLES, so I was
wondering
if this is also possible under Windows 2003 RRAS?


Thank You for any help and web links!



George Valkov

| Hello George,

Hello Ace! Thank You very much for Your replay, here are the details which
You requested:

| Interesting the ISP would do such a thing.
| Actually I've never heard that done,
| for it would eliminate any possibility of their
| customer base accessing the internet.

They relay on the fact that client computers accept packets with TTL=0, so
their clients can properly access the Internet. On the other hand, if a
client adds a router to share the connection with another PC or device, the
router will discard that packets. Please note TTL is only modified for
packets that travel from internet to the client, e.g.

[internet host sends packet with TTL=128] ->
[some internet router TTL-1=127] ->
[ISP GW sets TTL to 0] ->
[client with real IP, receives packet with TTL=0].

TTL is not set to 0 in the other direction e.g.
[client with real IP, sends packet with TTL=128] ->
[ISP GW TTL-1=127] ->
[some internet router TTL-1=126] - >
[internet host, receives packet with TTL=126].


| In order to prevent an IP packet from propagating endlessly
| through the network until eternity, there must be some
| mechanism to expire the packet, otherwise you would see
| packets flying around from 20 years ago. Therefore, the value
| in the TTL field is reduced by each router it hits until it expires
| (hitting 0), then at which the router will discard it.

Yes, I am aware of that.


| If there is
| congestion in the router, it may reduce it further, but there is
| no way or for any reason I can think of that an ISP would
| deliberately reduce the TTL to 0 unless their system is really
| slow, they have routers that are 15 years old that can't handle
| the traffic, etc.

My ISP www.megalan.bg want's to prevent the clients from sharing their
internet connection. Clients connect via RJ45 LAN and have a real internet
IPs, the link then continues in optical cables. The speed they offer about
30 MBit/s, not just in Bulgaria, but in the entire world. Delay is about 1ms
to most web sites and hosts in the Capital of Bulgaria. Being monopolist -
the only available choice for the students, they demand high prices and take
all possible measurements to prevent sharing of the connection.


| Also, I can't see a router "returning" or sending a packet
| with a 0 TTL. It would have just discarded it. So that
| doesn't make sense. How did come to that conclusion
| that they are 'sending' packets that way? Maybe there is
| a rule blocking ICMP echo?

Actually this is a known practice done by this and a few other ISPs. They
admit it. They also offer an option not to modify the TTL, but will then
reduce the number of active connections to 40. They also have MAC address
restriction, that can be easily overcome by changing the Network Address of
the LAN adapter from Device Manager ;-)



| Now if the ISP were blocking NAT type of traffic,
| which I know years ago Comcast used to do that to keep
| people from running NAT boxes so they can charge you
| for each computer you have (the old cable TV mentality),
| then I can see why, but they changed their tune on that
| many years ago because they were losing business to
| other ISPs that allow NATs.

Yes they want to charge the clients for every computer or device, but they
do the trick by modifying the TTL to prevent adding routers that share the
connection. On the other hand, some of the clients are using a linux box or
some advanced NAT router that does not discard packets with TTL=0, instead
the router increases the TTL back to some higher value ;-)

I was wondering if I can configure RRAS NAT to route the traffic without
discarding packets with TTL=0 and without reducing the TTL? By the way, the
[Virtual Machine Network Services] driver is doing something very
interesting, when the Virtual PC is in [Shared Networking (NAT)] mode. The
driver always changes the TTL to 128 and allows the Virtual PC to properly
access the internet - see the ping from the Virtual PC later in this post.
I'll be happy to do this with RRAS too.

For linux router, I was able to find this command:
iptables -t magle -I PREROUTING -i eth0 -j - -ttl-set 10

For windows, I was able to find two tools:
WinPacketFilter + ATTL
ATTL filters the traffic and modifies the TTL of packets and relays on
WinPacketFilter. The bad side is that and .exe must be running all the time
to patch the entire traffic, and I dodn't like it that way.



| Run a tracert and a pathping, and post the results
| to whatever you were pinging. I would like to see
| where it is getting hosed.


Right at the gateway: home-78-90-100-1.megalan.bg [78.90.100.1]


-------------- win2k3ent-home-server
[78.90.101.107] --------------------------------

#tracert www.abv.bg

Tracing route to www.abv.bg [194.153.145.104]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms home-78-90-100-1.megalan.bg [78.90.100.1]
2 1 ms 1 ms 1 ms 89.190.192.188
3 1 ms 2 ms 1 ms megalan-powernet.megalan.bg [89.190.192.34]
4 1 ms 2 ms 1 ms backuphosts2.powernet.bg [193.24.240.54]
5 2 ms 1 ms 1 ms abv.bg [194.153.145.104]

Trace complete.



#ping 78.90.100.1 -n 1

Pinging 78.90.100.1 with 32 bytes of data:

Reply from 78.90.100.1: bytes=32 time<1ms TTL=0

Ping statistics for 78.90.100.1:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms



#ping -n 1 www.abv.bg

Pinging www.abv.bg [194.153.145.104] with 32 bytes of data:

Reply from 194.153.145.104: bytes=32 time=1ms TTL=0

Ping statistics for 194.153.145.104:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms




#pathping www.abv.bg

Tracing route to www.abv.bg [194.153.145.104]
over a maximum of 30 hops:
0 win2k3ent-home-server [78.90.101.107]
1 home-78-90-100-1.megalan.bg [78.90.100.1]
2 89.190.192.188
3 megalan-powernet.megalan.bg [89.190.192.34]
4 backuphosts2.powernet.bg [193.24.240.54]
5 abv.bg [194.153.145.104]

Computing statistics for 125 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 win2k3ent-home-server
[78.90.101.107]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% home-78-90-100-1.megalan.bg
[78.90.100.1]
0/ 100 = 0% |
2 0ms 0/ 100 = 0% 0/ 100 = 0% 89.190.192.188
0/ 100 = 0% |
3 --- 100/ 100 =100% 100/ 100 =100% megalan-powernet.megalan.bg
[89.190.192.34]
0/ 100 = 0% |
4 1ms 0/ 100 = 0% 0/ 100 = 0% backuphosts2.powernet.bg
[193.24.240.54]
0/ 100 = 0% |
5 1ms 0/ 100 = 0% 0/ 100 = 0% abv.bg [194.153.145.104]

Trace complete.



-------------- Virtual PC - XP-SP3 in Shared Networking
(NAT) --------------------------------
#tracert www.abv.bg

Tracing route to www.abv.bg [194.153.145.104]
over a maximum of 30 hops:

1 8 ms 3 ms 5 ms 192.168.131.254
2 3 ms 1 ms 2 ms 89.190.192.188
3 3 ms 7 ms 5 ms megalan-powernet.megalan.bg [89.190.192.34]
4 2 ms 1 ms 2 ms backuphosts2.powernet.bg [193.24.240.54]
5 3 ms 2 ms 2 ms abv.bg [194.153.145.104]

Trace complete.

#ping -n 1 78.90.100.1

Pinging 78.90.100.1 with 32 bytes of data:

Request timed out.

Ping statistics for 78.90.100.1:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

#ping -n 1 89.190.192.188

Pinging 89.190.192.188 with 32 bytes of data:

Reply from 89.190.192.188: bytes=32 time=5ms TTL=128

Ping statistics for 89.190.192.188:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 5ms, Average = 5ms

#ping -n 1 abv.bg

Pinging abv.bg [194.153.145.104] with 32 bytes of data:

Reply from 194.153.145.104: bytes=32 time=2ms TTL=128

Ping statistics for 194.153.145.104:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2ms



#pathping www.abv.bg

Tracing route to www.abv.bg [194.153.145.104]
over a maximum of 30 hops:
0 xp-sp3 [192.168.131.66]
1 192.168.131.254
2 89.190.192.188
3 megalan-powernet.megalan.bg [89.190.192.34]
4 backuphosts2.powernet.bg [193.24.240.54]
5 abv.bg [194.153.145.104]

Computing statistics for 125 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 xp-sp3 [192.168.131.66]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% 192.168.131.254
0/ 100 = 0% |
2 1ms 0/ 100 = 0% 0/ 100 = 0% 89.190.192.188
0/ 100 = 0% |
3 --- 100/ 100 =100% 100/ 100 =100% megalan-powernet.megalan.bg
[89.190.192.34]
0/ 100 = 0% |
4 3ms 0/ 100 = 0% 0/ 100 = 0% backuphosts2.powernet.bg
[193.24.240.54]
0/ 100 = 0% |
5 2ms 0/ 100 = 0% 0/ 100 = 0% abv.bg [194.153.145.104]

Trace complete.

-------------- end of ICMP statistics --------------------------------


By the way I played a little bit with Wireshark, and it shows how the packet
sent from a Virtual PC attached to the private LAN card, is routed by RRAS
NAT to the GW of the ISP. I see in the sniffer that a replay comes back to
the RRAS NAT and get's discarded, because it has TTL=0.

George Valkov

So your ISP does prevent using NAT, as I suspected. Their devices scan for NAT headers and reduce the TTL to 0 on any packets that have a NAT header. If you find the Windows tool works, even though it is working all the time, then you don't have much choice other than ponying up extra money for the ability to use NAT. Or just use the Linux box.

Ace


.

Relevant Pages

  • Re: Routing and Remote Access NAT - I need to modify TTL
    ... with two interfaces: PUBLIC (internet) and PRIVATE ... use it as a gateway, they can access hosts on the PUBLIC interface, TTL is ... but the replay that comes back to the NAT ... They relay on the fact that client computers accept packets with TTL=0, ...
    (microsoft.public.windows.server.networking)
  • Re: Routing and Remote Access NAT - I need to modify TTL
    ... with two interfaces: PUBLIC (internet) and PRIVATE ... Hosts on the LAN successfully acquire IP addresses from the NAT SERVER ... use it as a gateway, they can access hosts on the PUBLIC interface, TTL ... They relay on the fact that client computers accept packets with TTL=0, ...
    (microsoft.public.windows.server.networking)
  • Re: Network Performance Issues.
    ... This is connected to a linux firewall/nat router ... One links out to the internet, ... from machine D go through machine S, which acts as a NAT translation. ... Is it a difficulty of machine S processing packets in on one NIC, ...
    (Debian-User)
  • Re: Plusnet 2Mbps connection
    ... so that each of them can Access the Internet. ... > The prob with things like M$ NetMeeting, ... > Most normal NAT things just Translate the IP Addresson the ... > in the *Data* part of the Packets. ...
    (uk.people.silversurfers)
  • Re: Linux als Router
    ... # Enter all trusted network interfaces here. ... # which should be available to the internet and set FW_ROUTE to yes. ... space separated list of ports, ... # Packets to silently reject without log message. ...
    (de.comp.os.unix.linux.misc)