Modify

Opened 4 years ago

Last modified 4 years ago

#14269 new defect

VPN routing bug

Reported by: bolvan Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: base system Version: Trunk
Keywords: routing vpn Cc:

Description

I use ISP with VPN dual access.
Ethernet WAN interface is configured by DHCP. Some DHCP routes applied to allow access only to some local resources. Internet is unavailable without connecting VPN.

VPN is L2TP with server IP 83.102.254.215.

Lets see what happens after wan connects and dhcp routes applied :

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        10.42.152.1     0.0.0.0         UG    0      0        0 eth0.1
10.0.0.0        10.42.152.1     255.0.0.0       UG    0      0        0 eth0.1
10.42.152.0     *               255.255.248.0   U     0      0        0 eth0.1
78.107.23.0     10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
78.107.52.0     10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
78.107.196.0    10.42.152.1     255.255.252.0   UG    0      0        0 eth0.1
83.102.146.96   10.42.152.1     255.255.255.224 UG    0      0        0 eth0.1
83.102.255.224  10.42.152.1     255.255.255.240 UG    0      0        0 eth0.1
85.21.72.80     10.42.152.1     255.255.255.240 UG    0      0        0 eth0.1
85.21.79.0      10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
85.21.90.0      10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
85.21.138.208   10.42.152.1     255.255.255.240 UG    0      0        0 eth0.1
89.179.134.64   10.42.152.1     255.255.255.240 UG    0      0        0 eth0.1
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
194.67.1.0      10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
194.67.18.0     10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
217.118.84.0    10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
233.32.240.0    10.42.156.42    255.255.255.0   UG    0      0        0 eth0.1

OK, now I connect l2tp interface.

default         bras41-lo0.spb. 0.0.0.0         UG    0      0        0 l2tp-bee
10.0.0.0        10.42.152.1     255.0.0.0       UG    0      0        0 eth0.1
10.42.152.0     *               255.255.248.0   U     0      0        0 eth0.1
78.107.23.0     10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
78.107.52.0     10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
78.107.196.0    10.42.152.1     255.255.252.0   UG    0      0        0 eth0.1
83.102.146.96   10.42.152.1     255.255.255.224 UG    0      0        0 eth0.1
83.102.254.215  10.42.152.1     255.255.255.255 UGH   0      0        0 eth0.1
83.102.254.215  *               255.255.255.255 UH    0      0        0 l2tp-bee
83.102.255.224  10.42.152.1     255.255.255.240 UG    0      0        0 eth0.1
85.21.72.80     10.42.152.1     255.255.255.240 UG    0      0        0 eth0.1
85.21.79.0      10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
85.21.90.0      10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
85.21.138.208   10.42.152.1     255.255.255.240 UG    0      0        0 eth0.1
89.179.134.64   10.42.152.1     255.255.255.240 UG    0      0        0 eth0.1
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
194.67.1.0      10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
194.67.18.0     10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
217.118.84.0    10.42.152.1     255.255.255.0   UG    0      0        0 eth0.1
233.32.240.0    10.42.156.42    255.255.255.0   UG    0      0        0 eth0.1

Two routes were added :

83.102.254.215  10.42.152.1     255.255.255.255 UGH   0      0        0 eth0.1
83.102.254.215  *               255.255.255.255 UH    0      0        0 l2tp-bee

1st is quite logical. Its needed to route traffic to l2tp server thru WAN. Otherwise we could cut ourselves off the L2TP server.
I dont understand purpose of 2nd route. But in this setup it does nothing bad.

Default route was replaced by l2tp connection. This happens because both interfaces have the same metric '0'. After disconnecting l2tp I lose default route for WAN and its very bad.
To overcome this problem I assign metric 10 to wan and 5 to l2tp.

Before l2tp :

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.42.152.1     0.0.0.0         UG    10     0        0 eth0.1
10.0.0.0        10.42.152.1     255.0.0.0       UG    10     0        0 eth0.1
10.42.152.0     *               255.255.248.0   U     10     0        0 eth0.1
78.107.23.0     10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
78.107.52.0     10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
78.107.196.0    10.42.152.1     255.255.252.0   UG    10     0        0 eth0.1
83.102.146.96   10.42.152.1     255.255.255.224 UG    10     0        0 eth0.1
83.102.255.224  10.42.152.1     255.255.255.240 UG    10     0        0 eth0.1
85.21.72.80     10.42.152.1     255.255.255.240 UG    10     0        0 eth0.1
85.21.79.0      10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
85.21.90.0      10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
85.21.138.208   10.42.152.1     255.255.255.240 UG    10     0        0 eth0.1
89.179.134.64   10.42.152.1     255.255.255.240 UG    10     0        0 eth0.1
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
194.67.1.0      10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
194.67.18.0     10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
217.118.84.0    10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
233.32.240.0    10.42.156.42    255.255.255.0   UG    10     0        0 eth0.1

after l2tp :

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         bras41-lo0.spb. 0.0.0.0         UG    5      0        0 l2tp-bee
default         10.42.152.1     0.0.0.0         UG    10     0        0 eth0.1
10.0.0.0        10.42.152.1     255.0.0.0       UG    10     0        0 eth0.1
10.42.152.0     *               255.255.248.0   U     10     0        0 eth0.1
78.107.23.0     10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
78.107.52.0     10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
78.107.196.0    10.42.152.1     255.255.252.0   UG    10     0        0 eth0.1
83.102.146.96   10.42.152.1     255.255.255.224 UG    10     0        0 eth0.1
83.102.254.215  *               255.255.255.255 UH    0      0        0 l2tp-bee
83.102.254.215  10.42.152.1     255.255.255.255 UGH   10     0        0 eth0.1
83.102.255.224  10.42.152.1     255.255.255.240 UG    10     0        0 eth0.1
85.21.72.80     10.42.152.1     255.255.255.240 UG    10     0        0 eth0.1
85.21.79.0      10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
85.21.90.0      10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
85.21.138.208   10.42.152.1     255.255.255.240 UG    10     0        0 eth0.1
89.179.134.64   10.42.152.1     255.255.255.240 UG    10     0        0 eth0.1
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
194.67.1.0      10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
194.67.18.0     10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
217.118.84.0    10.42.152.1     255.255.255.0   UG    10     0        0 eth0.1
233.32.240.0    10.42.156.42    255.255.255.0   UG    10     0        0 eth0.1

default gateway now has metric 5. Excellent.

Two additional routes :

83.102.254.215  *               255.255.255.255 UH    0      0        0 l2tp-bee
83.102.254.215  10.42.152.1     255.255.255.255 UGH   10     0        0 eth0.1

2nd is ok.
But 1st breaks everything ! It seem to be added always with metric 0.
Now traffic to l2tp server is routed to l2tp tunnel and connection drops very quickly because server cannot be accessed.

Seems to be a BUG.
I only have guesses what entity creates parasite route to l2tp-bee and how to prevent its creation. I havent found shell script for that. Problem can be in C code of netifd , xl2tpd, pppd, or wrong arguments passed to them.

In the same situation windows does not add this *bad* route and everything works fine.

Attachments (0)

Change History (4)

comment:1 Changed 4 years ago by anonymous

I created workaround.

1) install package 'ip'.

opkg update
opkg install ip

2) create /etc/hotplug.d/iface/01-fix-ptp-route

#!/bin/sh

[ "$ACTION" = ifup ] || exit 0

local ptp=$(ifconfig $DEVICE | grep "P-t-P" | awk -F: '{print $3}' | awk '{print $1}')
[ -n "$ptp" ] && {
 logger log -t fix-ptp-route deleting bad route to $ptp
 ip route del $ptp dev $DEVICE
}

3) set metric 10 for WAN, metric 5 to VPN
4) restart network

sample logread :

Oct  3 12:08:23 nata daemon.notice xl2tpd[2018]: Connecting to host tp.internet.beeline.ru, port 1701
Oct  3 12:08:23 nata daemon.notice netifd: bee (22819): 00 OK
Oct  3 12:08:23 nata daemon.notice xl2tpd[2018]: Connection established to 83.102.254.223, 1701.  Local: 46379, Remote: 45975 (ref=0/0).
Oct  3 12:08:23 nata daemon.notice xl2tpd[2018]: Calling on tunnel 46379
Oct  3 12:08:23 nata daemon.notice xl2tpd[2018]: Call established with 83.102.254.223, Local: 22036, Remote: 63950, Serial: 34 (ref=0/0)
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: start_pppd: I'm running: 
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: "/usr/sbin/pppd" 
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: "passive" 
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: "nodetach" 
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: ":" 
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: "file" 
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: "/tmp/l2tp/options.bee" 
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: "plugin" 
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: "pppol2tp.so" 
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: "pppol2tp" 
Oct  3 12:08:23 nata daemon.debug xl2tpd[2018]: "11" 
Oct  3 12:08:23 nata daemon.info pppd[22849]: Plugin pppol2tp.so loaded.
Oct  3 12:08:23 nata daemon.notice pppd[22849]: pppd 2.4.5 started by root, uid 0
Oct  3 12:08:23 nata daemon.info pppd[22849]: Using interface l2tp-bee
Oct  3 12:08:23 nata daemon.notice pppd[22849]: Connect: l2tp-bee <--> 
Oct  3 12:08:23 nata daemon.info pppd[22849]: CHAP authentication succeeded
Oct  3 12:08:23 nata daemon.notice pppd[22849]: CHAP authentication succeeded
Oct  3 12:08:23 nata daemon.notice pppd[22849]: local  IP address 95.24.94.163
Oct  3 12:08:23 nata daemon.notice pppd[22849]: remote IP address 83.102.254.223
Oct  3 12:08:23 nata daemon.notice pppd[22849]: primary   DNS address 85.21.192.5
Oct  3 12:08:23 nata daemon.notice pppd[22849]: secondary DNS address 213.234.192.7
Oct  3 12:08:23 nata daemon.notice netifd: Interface 'bee' is now up
Oct  3 12:08:24 nata user.notice fix-ptp-route: log deleting bad route to 83.102.254.223
Oct  3 12:08:24 nata user.notice firewall: Reloading firewall due to ifup of bee (l2tp-bee)

Now dual connection works fine.
But problem still needs investigation.

comment:2 Changed 4 years ago by anonymous

For increased durability add ppd-options lcp-echo-failure 5 lcp-echo-interval 3 :

config interface 'bee'
	option pppd_options 'nodeflate nobsdcomp nopcomp noaccomp lcp-echo-failure 5 lcp-echo-interval 3'

This gives 15 seconds before connection drops. Default is 5*1 (5 seconds). Its not always enough.

comment:3 Changed 4 years ago by bolvan

Even better solution :

1) install package 'ip'.

opkg update
opkg install ip

2) create /etc/ppp/ip-up.d/01-fix-ptp-route

#!/bin/sh

[ -n "$IPREMOTE" ] && {
 logger -t fix-ptp-route deleting bad route to $IPREMOTE
 ip route del $IPREMOTE dev $IFNAME
 local RETVAL=$?
 [ $RETVAL -ne 0 ] && logger -t fix-ptp-route failed to delete bad route to $IPREMOTE
 [ $RETVAL -eq 0 ] && logger -t fix-ptp-route deleted bad route to $IPREMOTE
}

3) chmod +x /etc/ppp/ip-up.d/01-fix-ptp-route
4) set metric 10 for WAN, metric 5 to VPN
5) restart network

Last edited 4 years ago by bolvan (previous) (diff)

comment:4 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.