Modify

Opened 3 years ago

Last modified 3 years ago

#18103 new defect

vpn only works after unplugging lan cable

Reported by: anon1 Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Barrier Breaker 14.07
Keywords: Cc:

Description

Tried on both TL wr710n and 841n routers. 14.07 final. An Openvpn setup that has worked on previous AA no problem, and similar to wiki page here - there are no unusual firewall settings.

The vpn connects ok - and a WiFi br-lan connection works well.

The problem is that there is only local access on the wired part of br-lan. There is access to Luci via ip address and a few bytes goes through to an internal IP on the VPN end, before freezing. This happens even while the wireless br-lan connection is working 100%.

The problem is resolved only by briefly unplugging and replugging the lan cable. It only needs to be done once and restarts of the vpn are not affected unless the router is powered down. I have tried simulating this as a workaround with ifup lan and ifconfig eth1 down/up, but this knocks over the wan (eth0) also, breaking the network.

Is there a way to trigger an equivalent to the physical hotplug event for lan/eth1 as a temporary workaround?

Note: The build has had ipv6 completely removed with imagebuilder:
make image PROFILE=TLWR710 PACKAGES="luci openvpn-polarssl kmod-ipt-nathelper-extra kmod-ipt-conntrack-extra -ip6tables -kmod-ip6tables -kmod-ipv6 -libip6tc -odhcp6c -odhcpd"
Sysctl.conf and /etc/config firewall, network have had references removed.
"dnsmasq" is restarted with no changes to dhcp (temporarily disabling/enabling dns only) before and after the vpn is up.

On both routers, everything works well both on wifi, and after physically replugging the cable. There is nothing unusual on the system or kernel logs, just this upon replug and it works:

daemon.notice netifd: Network device 'eth1' link is down
kern.info kernel: [ 456.860000] eth1: link down
kern.info kernel: [ 456.860000] br-lan: port 1(eth1) entered disabled state
kern.info kernel: [ 458.360000] eth1: link up (1000Mbps/Full duplex)
kern.info kernel: [ 458.360000] br-lan: port 1(eth1) entered forwarding state
kern.info kernel: [ 458.370000] br-lan: port 1(eth1) entered forwarding state
daemon.notice netifd: Network device 'eth1' link is up
kern.info kernel: [ 460.370000] br-lan: port 1(eth1) entered forwarding state
daemon.info dnsmasq-dhcp[1309]: DHCPREQUEST(br-lan) 192.168.
daemon.info dnsmasq-dhcp[1309]: DHCPACK(br-lan) 192.168.
daemon.info dnsmasq-dhcp[1309]: DHCPINFORM(br-lan) 192.168.
daemon.info dnsmasq-dhcp[1309]: DHCPACK(br-lan) 192.168.

Attachments (0)

Change History (1)

comment:1 Changed 3 years ago by anon1

Turns out to be either a dnsmasq issue or the right signals not getting through to dnsmasq.

If dns is disabled (port=0 in dnsmasq.conf) initially on boot, then enabling dns and restarting dnsmasq once the vpn is up, fails to activate dns on the wired lan although it works on the wireless. Somehow only physical replugging tells dnsmasq to listen and respond to dns on the wired lan also. After initial boot and after a replug (ie when restarting the vpn) disabling/re-enabling dns works fine on wired lan.

It seems after further testing, the wired link was actually working for direct IP connections through the vpn, at least for ssh, although accessing an https control panel hung after accepting the certificate.

Temporarily fixed by removing "port=0" to allow dns, and making use of "no-resolv" instead.

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.