LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   [Debian 5.0.4] Troubles with ip route/ip rule and PPTP protocol (https://www.linuxquestions.org/questions/linux-networking-3/%5Bdebian-5-0-4%5D-troubles-with-ip-route-ip-rule-and-pptp-protocol-799186/)

TVT 03-31-2010 02:19 PM
[Debian 5.0.4] Troubles with ip route/ip rule and PPTP protocol
 
Hi!

I've got a Linux router connected to two providers say Provider A and Provider B. All users divided in 2 groups: A and B. User group A access Internet thru Provider A (default route) and user group B thru Provider B (alternate).

There's also PPTP VPN server on the router and VPN users divided in 2 such groups too.

I use iproute2 to setup alternate route for users B and alternate routing is based on a source address. For example 192.168.0.188 is group B LAN user address and 192.168.11.65 is group B VPN user address.

Everything seems to be OK for all LAN users but group B VPN users fail to access Internet. Moreover, the most amazing is that group B VPN users can ping Internet hosts successfully as well as access LAN hosts.

I need some Guru's attention to comment this case.

Here is some info about network interfaces and routes
(eth0 -- inner interface, eth1, eth2 -- outer interfaces,
ppp1 -- Provider A, ppp0 -- Provider B,
ppp3 -- group B VPN user):

$ /sbin/ifconfig
Code:
eth0      Link encap:Ethernet  HWaddr 00:11:11:11:11:11
          inet addr:192.168.0.254  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::221:85ff:fe18:e424/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5051105 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7363689 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1994135710 (1.8 GiB)  TX bytes:9397026066 (8.7 GiB)
          Interrupt:254 Base address:0x4000

eth0:0    Link encap:Ethernet  HWaddr 00:11:11:11:11:11
          inet addr:192.168.11.254  Bcast:192.168.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:254 Base address:0x4000

eth1      Link encap:Ethernet  HWaddr 00:22:22:22:22:22
          inet addr:169.254.226.43  Bcast:169.254.255.255  Mask:255.255.0.0
          inet6 addr: fe80::222:b0ff:fee2:16a9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6970894 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4765366 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8979320498 (8.3 GiB)  TX bytes:1988629605 (1.8 GiB)
          Interrupt:20 Base address:0xe800

eth2      Link encap:Ethernet  HWaddr 00:33:33:33:33:33
          inet6 addr: fe80::222:b0ff:fee2:8ce/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:536056 errors:0 dropped:0 overruns:0 frame:0
          TX packets:401533 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:500511033 (477.3 MiB)  TX bytes:59745485 (56.9 MiB)
          Interrupt:21 Base address:0xe400

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3873 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3873 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:430124 (420.0 KiB)  TX bytes:430124 (420.0 KiB)

ppp0      Link encap:Point-to-Point Protocol
          inet addr:1.1.1.1  P-t-P:2.2.2.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:6943863 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4757647 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:8823299841 (8.2 GiB)  TX bytes:1883588150 (1.7 GiB)

ppp1      Link encap:Point-to-Point Protocol
          inet addr:3.3.3.3  P-t-P:4.4.4.4  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:531368 errors:0 dropped:0 overruns:0 frame:0
          TX packets:397419 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:486635643 (464.0 MiB)  TX bytes:50649094 (48.3 MiB)

ppp3      Link encap:Point-to-Point Protocol
          inet addr:192.168.11.1  P-t-P:192.168.11.65  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          RX packets:57 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:6675 (6.5 KiB)  TX bytes:5227 (5.1 KiB)
$ sudo ip rule ls
Code:
0:      from all lookup local
100:    from 192.168.0.0/16 to 192.168.0.0/16 lookup main
200:    from 1.1.1.1 lookup pb
200:    from 192.168.0.188 lookup pb
200:    from 192.168.0.189 lookup pb
200:    from 192.168.11.65 lookup pb
32766:  from all lookup main
32767:  from all lookup default
$ sudo ip route ls table pb
Code:
default dev ppp0  scope link
$ sudo ip route ls
Code:
192.168.11.65 dev ppp3  proto kernel  scope link  src 192.168.11.1
2.2.2.2 dev ppp0  proto kernel  scope link  src 1.1.1.1
4.4.4.4 dev ppp1  proto kernel  scope link  src 3.3.3.3
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.254
192.168.11.0/24 dev eth0  proto kernel  scope link  src 192.168.11.254
169.254.0.0/16 dev eth1  proto kernel  scope link  src 169.254.226.43
default dev ppp1  scope link
Thank you very much!

TVT 03-31-2010 03:16 PM
BTW, UDP protocol also works fine thru group B VPN connectipn:

C:\WINDOWS>nslookup -ty=a www.google.com. ns.google.com
Code:
Server:  ns1.google.com
Address:  216.239.32.10

Name:    www.l.google.com
Addresses:  74.125.87.105, 74.125.87.147, 74.125.87.106, 74.125.87.103
          74.125.87.99, 74.125.87.104
Aliases:  www.google.com

TVT 04-02-2010 04:03 PM
Seems I have found a cause of this phenomenon that means that I misunderstand the Linux routing logic. Taking in account that ppp2's (VPN client's) mtu is 1396 and ppp0's (Provider's B) is 1492 so the router has to inform remote site (say www.linuxquestions.org) to send smaller size packets with ICMP request 'NEED to FRAG'.

I just don't know the reason but such ICMP packets are sent to remote sites though thru interface ppp1 (Provider's A):

sudo tcpdump -pi ppp1 'icmp'
Code:
23:21:12.179872 IP 1.1.1.1 > www.linuxquestions.org: ICMP 1.1.1.1 unreachable - need to frag (mtu 1396), length 556
This is made despite(?) the routing policy:
$ sudo ip route ls table pb
Code:
...
default dev ppp0  scope link
...
$ sudo ip rule ls
Code:
...
200:    from 1.1.1.1 lookup pb
...
At the same time the ICMP 'Echo Request' packets go thru the proper interface:
$ sudo ping -I 1.1.1.1 8.8.8.8
Code:
PING 8.8.8.8 (8.8.8.8) from 1.1.1.1 : 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=34.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=246 time=33.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=246 time=33.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=246 time=33.8 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=246 time=34.6 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=246 time=33.7 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5019ms
rtt min/avg/max/mdev = 33.757/34.008/34.614/0.396 ms
$ sudo tcpdump -pni ppp0 'icmp'
Code:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
00:13:51.665437 IP 1.1.1.1 > 8.8.8.8: ICMP echo request, id 62049, seq 65, length 64
00:13:51.699331 IP 8.8.8.8 > 1.1.1.1: ICMP echo reply, id 62049, seq 65, length 64
00:13:52.669435 IP 1.1.1.1 > 8.8.8.8: ICMP echo request, id 62049, seq 66, length 64
00:13:52.703381 IP 8.8.8.8 > 1.1.1.1: ICMP echo reply, id 62049, seq 66, length 64
00:13:53.673436 IP 1.1.1.1 > 8.8.8.8: ICMP echo request, id 62049, seq 67, length 64
00:13:53.707524 IP 8.8.8.8 > 1.1.1.1: ICMP echo reply, id 62049, seq 67, length 64
^C
Could anybody of local Guru's comment this phenomenon? Thank you!


All times are GMT -5. The time now is 04:57 AM.