OpenWrt on ESXi resolving DNS properly until OpenConnect connection establishes

Hi there, bear with me here as I'm a new user to OpenWRT and a novice Linux user in general. Spent most of my career on Windows world.

I have two small vms running OpenWRT at my home lab ESXi (CHAOS CALMER (15.05, r46767)). Each one connects to a different VPN at work. These vpns are in different geographical locations very far apart (over 6000 miles). The reason why two is because once you are connected to one you can reach any other location from there, which in my case I don't want. If I'm connected to the 6K mile location I don't want to route from there to the assets I have 5 miles from home. I imagine there's some way to tinker with the routes on the OpenWRT device to reroute requests to one VPN or another, but I prefer the simpler approach of adding static routes in my layer 3 switch to one OpenWRT instance or another.
Anyway, the above works well, I have no problem with it.

What brings me here is the fact that once I establish the OpenConnect tunnel to either one of these locations the DNS resolution of the router itself stops working. Simple test is going to the diagnostics tool and try to ping dev.openwrt.org. It just replies with:

ping: bad address 'dev.openwrt.org

The second "bad thing" happening is that even if the VPN disconnects, most times I can't reconnect on the same boot of OpenWRT. Even with the VPN disconnected it can't resolve DNS therefore I can't OpenConnect back to the original VPN. The only option I'm left with is rebooting the vm.

This router is NOT doing DCHP or DNS to the devices in my network. It's only purpose is to tunnel connections specifically configured in my switch to the two VPNs I mentioned above. The only purpose of DNS working is so it can itself resolve the address of the VPN tunnels.

The configuration is pretty plan vanilla with the addition of the vpn connection. I have two virtual NICs, one for LAN and one for WAN.
Before someone asks, I do have a route in my switch to 129.168.2.0 network which works fine.

This is the network config:

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config interface 'lan'
	option ifname 'eth0'
	option type 'bridge'
	option _orig_ifname 'eth0'
	option _orig_bridge 'true'
	option proto 'static'
	option ipaddr '192.168.8.85'
	option netmask '255.255.255.0'
	option gateway '192.168.8.1'
	option dns '192.168.2.1'

config globals 'globals'
	option ula_prefix 'fd26:eabb:1009::/48'

config interface 'wan'
	option proto 'dhcp'
	option _orig_ifname 'eth1'
	option _orig_bridge 'true'
	option ifname 'eth1'
	option macaddr '00:0c:29:00:fb:9d'
	option hostname 'openwrt'

config interface 'MVD'
	option proto 'openconnect'
	option server <server>
	option username <user>
	option password <pwd>
	option authgroup <group>
	option interface 'wan'
	option port '443'
	option serverhash <hash>

This is my firewall config:

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config include
	option path '/etc/firewall.user'

config zone
	option input 'ACCEPT'
	option output 'ACCEPT'
	option name 'lan'
	option network 'lan'
	option forward 'ACCEPT'

config zone
	option output 'ACCEPT'
	option name 'wan'
	option input 'REJECT'
	option network 'wan'
	option masq '1'
	option mtu_fix '1'
	option forward 'REJECT'

config forwarding
	option dest 'lan'
	option src 'wan'

config forwarding
	option dest 'wan'
	option src 'lan'

config zone
	option input 'ACCEPT'
	option output 'ACCEPT'
	option name 'mvdvpn'
	option network 'MVD'
	option forward 'REJECT'

config forwarding
	option dest 'lan'
	option src 'mvdvpn'

config forwarding
	option dest 'mvdvpn'
	option src 'lan'

I'm not very familiar yet understanding the different options to configure in the firewall. For the most part I followed google links and trial and error until I got the stuff working... except for DNS resolution of the device itself.

Any help appreciated.

https://openwrt.org/docs/guide-user/services/vpn/openconnect/extras#dynamic_connection

https://openwrt.org/docs/guide-user/services/vpn/openconnect/extras#disable_gateway_redirection

1 Like

vgaetera, thanks for the quick response!

Ok, resetting the WAN to be a gateway with higher weight is easy. Done.
Trying to understand now the routing and the redirect on the firewall I can't get it to work.
First question, the VPN gateway is the IP reflected in the OC interface? If so, this IP changes in a round-robin fashion for the VPN I'm connecting so, so I tried adding to the route the network with the mask, I don't know if that will even even work for a static route.
See below:

network.vpn=route
network.vpn.interface='lan'
network.vpn.target='192.168.32.0/22'
network.vpn.gateway='192.168.107.0/32'

I implemented the firewall portion, but I can't get it to work. Data seems to be flowing to the VPN but not coming back. I don't see any data in the RX side.

This is my firewall config:

firewall.@defaults[0]=defaults
firewall.@defaults[0].syn_flood='1'
firewall.@defaults[0].input='ACCEPT'
firewall.@defaults[0].output='ACCEPT'
firewall.@defaults[0].forward='ACCEPT'
firewall.@include[0]=include
firewall.@include[0].path='/etc/firewall.user'
firewall.@zone[0]=zone
firewall.@zone[0].input='ACCEPT'
firewall.@zone[0].output='ACCEPT'
firewall.@zone[0].name='lan'
firewall.@zone[0].network='lan'
firewall.@zone[0].forward='ACCEPT'
firewall.@zone[1]=zone
firewall.@zone[1].output='ACCEPT'
firewall.@zone[1].name='wan'
firewall.@zone[1].input='REJECT'
firewall.@zone[1].network='wan'
firewall.@zone[1].masq='1'
firewall.@zone[1].mtu_fix='1'
firewall.@zone[1].forward='REJECT'
firewall.@forwarding[0]=forwarding
firewall.@forwarding[0].dest='lan'
firewall.@forwarding[0].src='wan'
firewall.@forwarding[1]=forwarding
firewall.@forwarding[1].dest='wan'
firewall.@forwarding[1].src='lan'
firewall.@zone[2]=zone
firewall.@zone[2].input='ACCEPT'
firewall.@zone[2].output='ACCEPT'
firewall.@zone[2].name='mvdvpn'
firewall.@zone[2].network='MVD'
firewall.@zone[2].forward='ACCEPT'
firewall.@zone[2].masq='1'
firewall.@zone[2].mtu_fix='1'
firewall.@forwarding[2]=forwarding
firewall.@forwarding[2].dest='lan'
firewall.@forwarding[2].src='mvdvpn'
firewall.@forwarding[3]=forwarding
firewall.@forwarding[3].dest='mvdvpn'
firewall.@forwarding[3].src='lan'
firewall.oc=redirect
firewall.oc.name='Redirect-OpenConnect'
firewall.oc.src_dport='443'
firewall.oc.dest_ip='192.168.107.0/32'
firewall.oc.family='ipv4'
firewall.oc.proto='tcp upd'
firewall.oc.target='DNAT'
firewall.oc.src='wan'
firewall.oc.dest='lan'

I'm building up a bit more networking knowledge, so I can't figure out this one...

Assuming that 192.168.32.0/22 is reachable over the VPN, the gateway should not be necessary and the interface should match your VPN:

uci -q delete network.vpn.gateway
uci set network.vpn.interface="MVD"
uci commit network
/etc/init.d/network restart
1 Like

Not working yet. It worked for a while when I set the route as you explained and I restarted the network. I rebooted the router and I'm seeing the same thing as before. Packets flowing into the VPN but nothing reported back and PING on the diagnostics page don't resolve.

One more thing, the VPN pushes a bunch of routes back, including 192.168.32.0/22 . In fact, when I was setting the static route the other way (including the gateway with a network) when I went to see active routes I never got see that one appearing.

Now after the reboot I'm just getting Request timeout for icmp_seq xxx.

This is how the network config looks like now:

network.loopback=interface
network.loopback.ifname='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.lan=interface
network.lan.ifname='eth0'
network.lan.type='bridge'
network.lan._orig_ifname='eth0'
network.lan._orig_bridge='true'
network.lan.proto='static'
network.lan.ipaddr='192.168.8.85'
network.lan.netmask='255.255.255.0'
network.lan.gateway='192.168.8.1'
network.lan.dns='192.168.2.1'
network.globals=globals
network.globals.ula_prefix='fd26:eabb:1009::/48'
network.wan=interface
network.wan.proto='dhcp'
network.wan._orig_ifname='eth1'
network.wan._orig_bridge='true'
network.wan.ifname='eth1'
network.wan.macaddr='00:0c:29:00:fb:9d'
network.wan.hostname='openwrt'
network.wan.metric='100'
network.MVD=interface
network.MVD.proto='openconnect'
network.MVD.server='<host>'
network.MVD.username='<user>'
network.MVD.password='<pwd>'
network.MVD.authgroup='<grp>'
network.MVD.interface='wan'
network.MVD.port='443'
network.MVD.serverhash='<hash>'
network.MVD.defaultroute='0'
network.vpn=route
network.vpn.target='192.168.32.0/22'
network.vpn.interface='MVD'

Firewall:

firewall.@defaults[0]=defaults
firewall.@defaults[0].syn_flood='1'
firewall.@defaults[0].input='ACCEPT'
firewall.@defaults[0].output='ACCEPT'
firewall.@defaults[0].forward='ACCEPT'
firewall.@include[0]=include
firewall.@include[0].path='/etc/firewall.user'
firewall.@zone[0]=zone
firewall.@zone[0].input='ACCEPT'
firewall.@zone[0].output='ACCEPT'
firewall.@zone[0].name='lan'
firewall.@zone[0].network='lan'
firewall.@zone[0].forward='ACCEPT'
firewall.@zone[1]=zone
firewall.@zone[1].output='ACCEPT'
firewall.@zone[1].name='wan'
firewall.@zone[1].input='REJECT'
firewall.@zone[1].network='wan'
firewall.@zone[1].masq='1'
firewall.@zone[1].mtu_fix='1'
firewall.@zone[1].forward='REJECT'
firewall.@forwarding[0]=forwarding
firewall.@forwarding[0].dest='lan'
firewall.@forwarding[0].src='wan'
firewall.@forwarding[1]=forwarding
firewall.@forwarding[1].dest='wan'
firewall.@forwarding[1].src='lan'
firewall.@zone[2]=zone
firewall.@zone[2].input='ACCEPT'
firewall.@zone[2].output='ACCEPT'
firewall.@zone[2].name='mvdvpn'
firewall.@zone[2].network='MVD'
firewall.@zone[2].forward='ACCEPT'
firewall.@zone[2].masq='1'
firewall.@zone[2].mtu_fix='1'
firewall.@forwarding[2]=forwarding
firewall.@forwarding[2].dest='lan'
firewall.@forwarding[2].src='mvdvpn'
firewall.@forwarding[3]=forwarding
firewall.@forwarding[3].dest='mvdvpn'
firewall.@forwarding[3].src='lan'
firewall.oc=redirect
firewall.oc.name='Redirect-OpenConnect'
firewall.oc.src_dport='443'
firewall.oc.dest_ip='192.168.107.0/32'
firewall.oc.family='ipv4'
firewall.oc.proto='tcp upd'
firewall.oc.target='DNAT'
firewall.oc.src='wan'
firewall.oc.dest='lan'

Not sure what's the purpose of that Redirect-OpenConnect in this case, and I don't know if it's right or not.

The VPN IS connecting. Data flows into it, but nothing seems to come back.

Definitively odd. Rebooted the vm one more time, and now it's responding ping but the diagnostics name resolution is not working. So I guess is somehow still trying to tunnel thorough the VPN for name resolution.

One more piece of information. If I shutdown the VPN interface I would expect for diagnostics name resolution to work again assuming it was tunneling these request via the VPN now that we changed the metric and increased the WAN metric to 100.
Well, it's not working.

If I try to reconnect to the VPN I get this in the system log:

Sat Jun 12 17:16:43 2021 user.notice openconnect: executing 'openconnect <VPN Host Name>:443 -i vpn-MVD --non-inter --syslog --script /lib/netifd/vpnc-script  --servercert=<hash> --no-system-trust --authgroup <auth_grp> -u <user_name> --passwd-on-stdin'
Sat Jun 12 17:16:43 2021 daemon.notice netifd: MVD (31097): WARNING: This version of openconnect was built without iconv
Sat Jun 12 17:16:43 2021 daemon.notice netifd: MVD (31097):          support but you appear to be using the legacy character
Sat Jun 12 17:16:43 2021 daemon.notice netifd: MVD (31097):          set "ASCII". Expect strangeness.
Sat Jun 12 17:16:43 2021 daemon.info openconnect[31099]: POST <VPN Host Name>
Sat Jun 12 17:16:43 2021 daemon.notice openconnect[31099]: getaddrinfo failed for host '<VPN Host Name>': Name or service not known
Sat Jun 12 17:16:43 2021 daemon.notice openconnect[31099]: Failed to open HTTPS connection to <VPN Host Name>
Sat Jun 12 17:16:43 2021 daemon.notice netifd: MVD (31097): Failed to obtain WebVPN cookie
Sat Jun 12 17:16:43 2021 user.notice openconnect: bringing down openconnect

Clearly name resolution is not working. I would expect it should stop using the VPN as a gateway for non-local resolutions, but it appears it's still trying therefore not resolving even the host name of the VPN itself. I guess I could out a static entry within the OpenWRT vm itself, but I kind of don't like having this "half working". It clearly should do a true split-tunnel and send everything but what is routable thorough the VPN via the WAN, including internal DNS resolution requests.

Added my VPN host to the hosts file and the VPN that could not resolve the name immediately reconnected. Clearly after one connection name resolution using external DNS responder stops properly working.
I may go back to the simpler config (with gateway set to VPN) and keep host name in the hosts file if I can't figure out how to resolve this.

While I might occasionally sound like a broken record, please consider upgrade to a supported OpenWrt release urgently. Not only has 15.05.x been out of support for over 4 years now and has accumulated serious/ known security issues, progress and bugfixes in VPN tools and networking/ routing haven't missed the more modern releases either; barely anyone remembers specifics about older ones anymore. Especially with (emulated-) x86/ x86_64 there shouldn't be the slightest problem to update.

2 Likes
uci set network.MVD.peerdns="0"
uci commit network
/etc/init.d/network restart

slh, I've tried two-three times already to upgrade these vms. All times I tried downloading the upgrade image from the link the the article I ended up bricking them. Good thing I took an ESXi snapshot which got them to life immediately.
I also tried with an OVA file found in the same article which requires re-configuring the device with my settings from my currently working vms. No luck either, I could not get it to see the internet properly (maybe DNS resolution or something) and with that I could not install missing packages to make this config work.
I've been trying to get them up to date, but has been a frustrating process, so I re-focused to get them reliably working doing what I want them to do which is tunnel to a specific VPN per box.
I didn't want to even try hosting both vpns on the same box as they have conflicting routes. All our endpoints can route to anywhere else in the network, so I can only guess it won't be simple to be able to run these vpns in tandem, therefore I chose to run two boxes and have the routes in my switch to select which way to go (knowing the distance to the hosts).

vgaetere, thanks for the reply.
I think for now I'm going to leave these vms where they are. They are working by adding an entry to the hosts file and in fact I've disabled the DNS and DHCP services, which I don't need.

15.05.x --> 17.01.x will require discarding the old configuration, as it isn't compatible (enough), 21.02.x will bring very considerable configuration as well, so I'd personally suggest to start over with 21.02.0-rc2 (or newer). Even if the sysupgrade fails, it should be trivial to create a new image with a current/ supported OpenWrt version, it's a simple VM after all.

--
Disclaimer: I've never used VMware so far, but it works fine for me with qemu (kvm) - and I haven't used 15.05.x in a long time.

slh, any tips where to start without an OVA file? Any link or article?
Every attempt I did to build myself the vmdk failed with OpenWRT booting up and crashing at some point going to a panic or infinite loop of restarts. The version 15 I got I downloaded as an OVA file I imported into ESXi.

I see this wiki article is woefully out of date

That's the article where I ended up getting the working OVA for version 15.
I also pulled the version 19 OVA and had tons of problems to make it functional. That's when I dropped the effort and decided to learn and make version 15 at least work with my config

Trying to get the OVA for version 19 going following this article for OpenConnect https://openwrt.org/docs/guide-user/services/vpn/openconnect/client eventually I get stuck to trying to add OpenConnect interface.

At one point the article asks to execute:

uci set network.${OC_IF}="interface"

And I get from OpenWRT:

uci: Invalid argument

And it's game over there.

One more interesting thing is that if trying to add OpenConnect using LuCI using the "Add new interface" button on the protocol drop down there's no OpenConnect option like I have in my currently working version 15 of OpenWRT.

I did reboot to see if it was needed after installing the OpenConnect package yet no OpenConnect protocol option appears and the uci command still fails. So, this box version 19 is no good to use OpenConnect or I'm missing some step or something to have OpenConnect fully usable and functional within it.