I have encountered a possible problem in my VPN setup. I have two different entry points into clients network, so I set two services up and, since one of the VPN-connections is slightly better for us, set it's metric to 100 and another to 101 like following.
/etc/ppp/ip-up.local
metric=100
if [[ $PPP_IFACE == 'ppp2' ]]; then
metric=101;
# ppp2 have lower priority
fi;
route add -net 10.20.0.0 netmask 255.255.0.0 dev $PPP_IFACE metric $metric
The interface names are set in /etc/ppp/*.options with unit 2 and unit 3:
ipcp-accept-local
ipcp-accept-remote
refuse-eap
require-chap
noccp
noauth
#noaccomp
mtu 1280
mru 1280
noipdefault
#defaultroute
nodefaultroute
#usepeerdns
unit 2
connect-delay 5000
name myname
password mypassword
Since I knew the names of the interfaces, I was lazy and just added fix rules to iptables and thought I was done with it (instead of adding/removing them in a script).
But then I saw an ppp0 interface...
Some research got me this.
sudo grep -iRn "pppd" /var/log/ give me this
/var/log/syslog:5697:Jul 29 10:55:58 debian-router pppd[5153]: LCP terminated by peer
/var/log/syslog:5698:Jul 29 10:55:58 debian-router pppd[5153]: Connect time 643.1 minutes.
/var/log/syslog:5699:Jul 29 10:55:58 debian-router pppd[5153]: Sent 0 bytes, received 0 bytes.
/var/log/syslog:5702:Jul 29 10:55:58 debian-router pppd[5153]: Overriding mtu 1500 to 1280
/var/log/syslog:5703:Jul 29 10:55:58 debian-router pppd[5153]: Overriding mru 1500 to mtu value 1280
/var/log/syslog:5707:Jul 29 10:55:58 debian-router xl2tpd[3016]: Terminating pppd: sending TERM signal to pid 5153
/var/log/syslog:5708:Jul 29 10:55:58 debian-router pppd[5153]: Terminating on signal 15
/var/log/syslog:5713:Jul 29 10:56:01 debian-router xl2tpd[3016]: start_pppd: I'm running:
/var/log/syslog:5714:Jul 29 10:56:01 debian-router xl2tpd[3016]: "/usr/sbin/pppd"
/var/log/syslog:5724:Jul 29 10:56:01 debian-router pppd[5613]: Plugin pppol2tp.so loaded.
/var/log/syslog:5725:Jul 29 10:56:01 debian-router pppd[5613]: pppd 2.4.7 started by root, uid 0
/var/log/syslog:5726:Jul 29 10:56:01 debian-router pppd[5613]: Couldn't allocate PPP unit 2 as it is already in use
/var/log/syslog:5727:Jul 29 10:56:01 debian-router pppd[5613]: Using interface ppp0
/var/log/syslog:5728:Jul 29 10:56:01 debian-router pppd[5613]: Connect: ppp0 <-->
/var/log/syslog:5729:Jul 29 10:56:01 debian-router pppd[5613]: Overriding mtu 1500 to 1280
/var/log/syslog:5730:Jul 29 10:56:01 debian-router pppd[5613]: Overriding mru 1500 to mtu value 1280
/var/log/syslog:5732:Jul 29 10:56:01 debian-router pppd[5613]: Overriding mtu 1500 to 1280
/var/log/syslog:5733:Jul 29 10:56:01 debian-router pppd[5613]: PAP authentication succeeded
/var/log/syslog:5734:Jul 29 10:56:01 debian-router pppd[5153]: Connection terminated.
/var/log/syslog:5736:Jul 29 10:56:01 debian-router pppd[5153]: Modem hangup
/var/log/syslog:5737:Jul 29 10:56:01 debian-router pppd[5153]: Exit.
So what happens must be... For some (probably irrelevant) reason the connection is terminated, upon which xl2tpd sends TERM to the pppd[5153] and then starts new pppd[5613] for the new connection. But pppd[5153] needs some time to exit and so pppd[5613] can't use designated interface name ppp2.
/etc/xl2tpd/xl2tpd.conf is like this.
[lac vpn1]
lns = 10.20.30.40
;ppp debug = yes
pppoptfile = /etc/ppp/options.vpn1.l2tpd
length bit = yes
redial = yes
redial timeout = 2
; max redials = 15
[lac vpn2]
lns = 10.20.30.41
;ppp debug = yes
pppoptfile = /etc/ppp/options.vpn2.l2tpd
length bit = yes
redial = yes
redial timeout = 2
; max redials = 15
Now, I guess I could set redial timeout in xl2tpd.conf higher, but it wouldn't be very clean solution to the problem. So the question is, is it possible to ensure device name is kept across reconnects? (If not I guess I could just use $PPP_REMOTE -- but not really, since it's not the lns = 10.20.30.41! -- in my ip-up.local instead of $PPP_IFACE and add/remove iptables rules there too, but maybe there is a better way).
Update
I added ipparam vpn1 and ipparam vpn2 to the /etc/ppp/*.options files and use $PPP_IPPARAM to distinguish between the two; I guess this is the most stable solution.
Additional info:
- OS: Debian GNU/Linux 10 (buster)
- ipsec: Linux strongSwan U5.7.2/K4.19.0-9-amd64
- xl2tpd: xl2tpd-1.3.12
0 Answers