You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A USB LTE dongle gets the internet, with a non-public IPv4 address, using either "3g" or "ncm" protocol.
There is a PPtP tunnel to PureVPN that gets a static public IPv4 address.
There is a 6in4 tunnel to he.net that gets IPv6.
The idea here is that the 6in4 tunnel (and everything else) should go through the VPN. However, on boot, LEDE brings up the 6in4 tunnel before the VPN connects, and adds this route:
216.218.221.6 via 100.81.185.161 dev wwan0
This route never gets deleted, and so 6in4 packets go through the LTE dongle, not through the VPN. If I reconnect the 6in4-wan6 interface, it removes this route and reroutes through the VPN, as it should.
The bug is that there are two valid setups regarding interface dependencies here (1: "6in4 should go through LTE", 2: "6in4 should go through PPtP"), and there is no way, or no documented way, to say which one actually applies.
I was able to work around this bug (thanks friendofafriend on #openwrt) by putting a script in /etc/hotplug.d/iface that removes the route. But, this is only a workaround.
# cat /etc/config/network
# irrelevant parts, like disabled interfaces, are omitted
config interface 'wan6'
option proto '6in4'
option ipaddr '' # matches the static IP I get from the VPN
option peeraddr '216.218.221.6'
option ip6addr ''
option ip6prefix '::/64'
The strange order of sections is because this router was earlier on ADSL, and now I moved to a place where only LTE is available. So the tunnel was there before the move, and the usblte and VPN configs were added after the move.
patrakov:
This is reported on LEDE-17.01.4.
The setup is:
The idea here is that the 6in4 tunnel (and everything else) should go through the VPN. However, on boot, LEDE brings up the 6in4 tunnel before the VPN connects, and adds this route:
216.218.221.6 via 100.81.185.161 dev wwan0
This route never gets deleted, and so 6in4 packets go through the LTE dongle, not through the VPN. If I reconnect the 6in4-wan6 interface, it removes this route and reroutes through the VPN, as it should.
The bug is that there are two valid setups regarding interface dependencies here (1: "6in4 should go through LTE", 2: "6in4 should go through PPtP"), and there is no way, or no documented way, to say which one actually applies.
I was able to work around this bug (thanks friendofafriend on #openwrt) by putting a script in /etc/hotplug.d/iface that removes the route. But, this is only a workaround.
# cat /etc/config/network # irrelevant parts, like disabled interfaces, are omitted
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
config interface 'lan'
option type 'bridge'
option ifname 'eth1'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '192.168.7.1'
option ip6assign '64'
config interface 'wan6'
option proto '6in4'
option ipaddr '' # matches the static IP I get from the VPN
option peeraddr '216.218.221.6'
option ip6addr ''
option ip6prefix '::/64'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '2 3 4 5 0'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '1 6'
config interface 'usblte'
option proto 'ncm'
option ifname 'wwan0'
option device '/dev/cdc-wdm0'
option apn ''
option delay '6'
option auto '1'
config interface 'VPN'
option proto 'pptp'
option server 'hk-ded-1.pointtoserver.com'
option username ''
option password ''
option peerdns '0'
option dns '8.8.8.8'
The text was updated successfully, but these errors were encountered: