Routing and Remote Access NAT - I need to modify TTL

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

"George Valkov" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
> 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,

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.

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. 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.

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?

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.

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.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer
(E-Mail Removed)

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right things." - Peter F. Drucker
http://twitter.com/acefekay

"Ace Fekay [Microsoft Certified Trainer]" <(E-Mail Removed)>
wrote in message news:%(E-Mail Removed)...
"George Valkov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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


--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer
(E-Mail Removed)

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right
things." - Peter F. Drucker
http://twitter.com/acefekay

"George Valkov" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
>
> "Ace Fekay [Microsoft Certified Trainer]" <(E-Mail Removed)>
> wrote in message news:%(E-Mail Removed)...
> "George Valkov" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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

"Ace Fekay [Microsoft Certified Trainer]" <(E-Mail Removed)>
wrote in message news:(E-Mail Removed)...
"George Valkov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Ace Fekay [Microsoft Certified Trainer]" <(E-Mail Removed)>
> wrote in message news:%(E-Mail Removed)...
> "George Valkov" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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


Not just packets with NAT header. They modify all packets that pass through
the gateway to my computer. Also because of the ARP poisoning they do, If we
don't use static ARP, they also intercept the traffic between my computer
and my room-mate's. So if I ping his PC and receive TTL=0, this indicates
that he forgot to run the static-arp.cmd script and the gateway is tampering
with the packets. We pay for two computers - each has own real IP and we
have a local switch in the room. 20% extra money for the second PC is okay
and we don't have to worry about anything.

I started this topic just for knowledge - to learn if it's possible to route
the packets under Windows 2003 without discarding those with TTL=0.
Currently I don't need to use NAT. Any computer that may connect to my VPN
from the Internet already has access to Internet. ;-)

Thank You for Your time, Ace! If I find anything interesting on the topic, I
shall post it here.


George Valkov

"George Valkov" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
>
> Not just packets with NAT header. They modify all packets that pass through
> the gateway to my computer. Also because of the ARP poisoning they do, If we
> don't use static ARP, they also intercept the traffic between my computer
> and my room-mate's. So if I ping his PC and receive TTL=0, this indicates
> that he forgot to run the static-arp.cmd script and the gateway is tampering
> with the packets. We pay for two computers - each has own real IP and we
> have a local switch in the room. 20% extra money for the second PC is okay
> and we don't have to worry about anything.
>
> I started this topic just for knowledge - to learn if it's possible to route
> the packets under Windows 2003 without discarding those with TTL=0.
> Currently I don't need to use NAT. Any computer that may connect to my VPN
> from the Internet already has access to Internet. ;-)
>
> Thank You for Your time, Ace! If I find anything interesting on the topic, I
> shall post it here.
>
>
> George Valkov

Hi George,

Not that I know of directly using RRAS can you do this, but you've found 3rd party software that will. This is an interesting and unique issue that I haven't seen before. Interesting because of the way your ISP hordes their connections and pretty much act like the cable TV companies with their old 'charge per machine' mentality as if they were TV sets. I guess they must be the only game in town, so they can do it! Boy, they must have a monopoly in Bulgaria!

Good luck, George!

Cheers!

Ace

"Ace Fekay [Microsoft Certified Trainer]" <(E-Mail Removed)>
wrote in message news:(E-Mail Removed)...
"George Valkov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> Not just packets with NAT header. They modify all packets that pass
> through
> the gateway to my computer. Also because of the ARP poisoning they do, If
> we
> don't use static ARP, they also intercept the traffic between my computer
> and my room-mate's. So if I ping his PC and receive TTL=0, this indicates
> that he forgot to run the static-arp.cmd script and the gateway is
> tampering
> with the packets. We pay for two computers - each has own real IP and we
> have a local switch in the room. 20% extra money for the second PC is okay
> and we don't have to worry about anything.
>
> I started this topic just for knowledge - to learn if it's possible to
> route
> the packets under Windows 2003 without discarding those with TTL=0.
> Currently I don't need to use NAT. Any computer that may connect to my VPN
> from the Internet already has access to Internet. ;-)
>
> Thank You for Your time, Ace! If I find anything interesting on the topic,
> I
> shall post it here.
>
>
> George Valkov

Hi George,

| Not that I know of directly using RRAS can you do this, but you've found
| 3rd party software that will. This is an interesting and unique issue that
I
| haven't seen before. Interesting because of the way your ISP hordes their
| connections and pretty much act like the cable TV companies with their
| old 'charge per machine' mentality as if they were TV sets. I guess they
| must be the only game in town, so they can do it! Boy, they must have
| a monopoly in Bulgaria!

| Good luck, George!

| Cheers!

| Ace

"Ace Fekay [Microsoft Certified Trainer]" <(E-Mail Removed)>
wrote in message news:(E-Mail Removed)...
"George Valkov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> Not just packets with NAT header. They modify all packets that pass
> through
> the gateway to my computer. Also because of the ARP poisoning they do, If
> we
> don't use static ARP, they also intercept the traffic between my computer
> and my room-mate's. So if I ping his PC and receive TTL=0, this indicates
> that he forgot to run the static-arp.cmd script and the gateway is
> tampering
> with the packets. We pay for two computers - each has own real IP and we
> have a local switch in the room. 20% extra money for the second PC is okay
> and we don't have to worry about anything.
>
> I started this topic just for knowledge - to learn if it's possible to
> route
> the packets under Windows 2003 without discarding those with TTL=0.
> Currently I don't need to use NAT. Any computer that may connect to my VPN
> from the Internet already has access to Internet. ;-)
>
> Thank You for Your time, Ace! If I find anything interesting on the topic,
> I
> shall post it here.
>
>
> George Valkov

Hi George,

| Not that I know of directly using RRAS can you do this, but you've found
| 3rd party software that will. This is an interesting and unique issue that
I
| haven't seen before. Interesting because of the way your ISP hordes
| their connections and pretty much act like the cable TV companies with
| their old 'charge per machine' mentality as if they were TV sets. I guess
| they must be the only game in town, so they can do it! Boy, they must
| have a monopoly in Bulgaria!

| Good luck, George!

| Cheers!

| Ace



About 3 years ago the students were building their own free LANs
interconnecting computers on one or more blocks (hostel). Everyone who
joined, brought his/her own cabling and paid once just to cover the money
for a port of a switch. The bad thing was that organisation was poor, cables
were passing through windows and terraces and there were long cables from
one block to another. Some terraces did look like huge spider webs :-) WWW
;-)
A few ISPs were connected to the same LANs. Back then, the Internet was
slow, there were outages, viruses... It's was a wild and free network.

Then came megalan, as far as I heard they made some deal with the university
and became monopolist among the students town. Broke all the free networks.
Now there are no worms and the only one APR poisoning the network is the ISP
it self - they said to filter File and Printer Sharing and prevent worms
from spreading.

In fact the main reason for the ARP poisoning is to monitor all of the
traffic and determine if some of the clients wants to share the connection
or perform something that the ISP doesn't like. If a packet from
MAC-ADDRESS_A but IP_B arrives at the gateway, they consider that A is
trying to steal the IP of B, so they block access to the MAC-ADDRESS_A. I
wonder if they know that since custom MAC addresses can be assigned any bad
guy can cause denial of service on other clients by using their MAC with a
different IP, causing the security system to block MAC-ADDRESS_A. A client
can also set two computers to make a lot of traffic to each other, and
because of the ARP poisoning, that appears to be an innocent way to flood
the gateway. But they don't seem to understand how dangerous their security
measurements can be.

Good night, Ace!


George Valkov

"George Valkov" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
> About 3 years ago the students were building their own free LANs
> interconnecting computers on one or more blocks (hostel). Everyone who
> joined, brought his/her own cabling and paid once just to cover the money
> for a port of a switch. The bad thing was that organisation was poor, cables
> were passing through windows and terraces and there were long cables from
> one block to another. Some terraces did look like huge spider webs :-) WWW
> ;-)
> A few ISPs were connected to the same LANs. Back then, the Internet was
> slow, there were outages, viruses... It's was a wild and free network.
>
> Then came megalan, as far as I heard they made some deal with the university
> and became monopolist among the students town. Broke all the free networks.
> Now there are no worms and the only one APR poisoning the network is the ISP
> it self - they said to filter File and Printer Sharing and prevent worms
> from spreading.
>
> In fact the main reason for the ARP poisoning is to monitor all of the
> traffic and determine if some of the clients wants to share the connection
> or perform something that the ISP doesn't like. If a packet from
> MAC-ADDRESS_A but IP_B arrives at the gateway, they consider that A is
> trying to steal the IP of B, so they block access to the MAC-ADDRESS_A. I
> wonder if they know that since custom MAC addresses can be assigned any bad
> guy can cause denial of service on other clients by using their MAC with a
> different IP, causing the security system to block MAC-ADDRESS_A. A client
> can also set two computers to make a lot of traffic to each other, and
> because of the ARP poisoning, that appears to be an innocent way to flood
> the gateway. But they don't seem to understand how dangerous their security
> measurements can be.
>
> Good night, Ace!
>
>
> George Valkov

Ahh, very interesting, indeed! This all makes sense now. So this was a way for the ISP to control this mess and not allow this haphazard sharing one connection for the whole city block. They still do that with cable TV in some areas, I hear, or at least stealing or sharing a neighbor's cable TV connection. I guess that will never stop, but the digital boxes make it difficult to get premium channels without the box.

I can also see how based on your explanation, spoofing a MAC can cause problems with others. I guess as long as all users do not know other users' MACs, they will not cause any type of DOS on someone else's machine.

Cheers!

Ace

"Ace Fekay [Microsoft Certified Trainer]" <(E-Mail Removed)>
wrote in message news:(E-Mail Removed)...
"George Valkov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> About 3 years ago the students were building their own free LANs
> interconnecting computers on one or more blocks (hostel). Everyone who
> joined, brought his/her own cabling and paid once just to cover the money
> for a port of a switch. The bad thing was that organisation was poor,
> cables
> were passing through windows and terraces and there were long cables from
> one block to another. Some terraces did look like huge spider webs :-) WWW
> ;-)
> A few ISPs were connected to the same LANs. Back then, the Internet was
> slow, there were outages, viruses... It's was a wild and free network.
>
> Then came megalan, as far as I heard they made some deal with the
> university
> and became monopolist among the students town. Broke all the free
> networks.
> Now there are no worms and the only one APR poisoning the network is the
> ISP
> it self - they said to filter File and Printer Sharing and prevent worms
> from spreading.
>
> In fact the main reason for the ARP poisoning is to monitor all of the
> traffic and determine if some of the clients wants to share the connection
> or perform something that the ISP doesn't like. If a packet from
> MAC-ADDRESS_A but IP_B arrives at the gateway, they consider that A is
> trying to steal the IP of B, so they block access to the MAC-ADDRESS_A. I
> wonder if they know that since custom MAC addresses can be assigned any
> bad
> guy can cause denial of service on other clients by using their MAC with a
> different IP, causing the security system to block MAC-ADDRESS_A. A client
> can also set two computers to make a lot of traffic to each other, and
> because of the ARP poisoning, that appears to be an innocent way to flood
> the gateway. But they don't seem to understand how dangerous their
> security
> measurements can be.
>
> Good night, Ace!
>
>
> George Valkov

| Ahh, very interesting, indeed! This all makes sense now. So this was a way
| for the ISP to control this mess and not allow this haphazard sharing one
| connection for the whole city block. They still do that with cable TV in
some
| areas, I hear, or at least stealing or sharing a neighbor's cable TV
connection.
| I guess that will never stop, but the digital boxes make it difficult to
get premium
| channels without the box.

I've heard that some sattelite digital boxes like DreamBox (which runs on
Linux) can share their card over the Internet, when internet connection is
available (RJ45 LAN cable). Then the other DreamBox can use that shared card
to decrypt the premium channels. :-) So the cable operators started to offer
receivers very cheep. The boxes have custom firmware and will lock down if
not used on with that provider for 3 days. When the box plays a channel from
the provider, the timer gets reset and the box unlocked.


I can also see how based on your explanation, spoofing a MAC can cause
| problems with others. I guess as long as all users do not know other
users'
| MACs, they will not cause any type of DOS on someone else's machine.

| Cheers!

| Ace


You are right! That really makes sence! Finding other users' MACs is a very
hard task, I was able to accidently find 3 MACs a few months ago. Then I
learned that the static APR assignment must be on the both sides, otherwise
the GW still get's in the middle, but in one direction only. Packets with
others MACs almost never reach my computer. Even those from my room-mate's
PC that is connected to the same switch. Unless maby if I change mine's MAC
and IP to those of the GW and start heavy poisoning like them too. ;-)


George Valkov