Port Forwarding: WAN -> OpenConnect client

Hell everyone,

I've set up an OpenWRT router with OpenConnect Server and a vpn client has successfully connected from the outside (via WAN) and received the IP 192.168.100.X . Now I want to set up a port forwarding rule from the router's public IP (WAN) to the connected vpn client 192.168.100.X. But, what do I choose for "Destination zone"? The only available choices are unspecified, lan, and wan. Neither of the first two works.

Other forwarding rules WAN -> LAN(192.168.1.Y) do work properly.

It seems to be the same problem as in this post, but I can't find a solution there and the thread is closed.

Anyone can help?

1 Like

The destination should match the zone which the VPN server interface is assigned to.

Thanks, this motivated me to create an 'Unmanaged' interface in the web UI for the physical interface vpns0 (which also appeared in the VPN's active users list) and add it to the lan zone. (I guessed that 'DHCP client' and 'Static address' were inappropriate because vpn had already assigned an IP address.) For the port forwarding rule I then selected lan as the destination zone.

This way the web server behind that VPN client X does indeed reply when called through my router's WAN IP/domain (e.g. https://my_domain:PORT). But only if I call it from inside my LAN. Requests from other machines in the wild are forwarded through my router and the vpn connetion to the web server but all responses seem to be routed through the wrong interface on the web server instead of the vpn tun0 device where the requests came from. Any idea how to fix that without forcing all packets trough tun0 there?

You can enable masquerading on the VPN firewall zone.

Maybe I need to mention that currently there is an SSH tunnel for exposing the web server's port on the router's WAN interface (the server itself is behind a NAT router which I have no access to). The SSH tunnel hides the true source address of requests arriving at the web server. That's why I'm exploring VPN connections as an alternative.
Masquerading would throw me back to the same limitations as with the SSH tunnel (hiding origin of HTTP requests), if I understand it correctly.

Then it's really a matter of proper routing setup on the web server machine, where the VPN connection is initiated. Anyone knows a good guide for setting this up with openconnect on debian?

1 Like

Yep, then you should look into the webserver side routing, but it seems no longer related to OpenWrt.

I learned that the OpenConnect server can push routes to connecting clients. Is there a way for the OpenConnect server on the OpenWrt router to push routes to the client so that all packets with source_address == vpn_client_IP from the client are routed through the VPN connection?

You can change the default route on the VPN client, or enable masquerading on the VPN server.
Unless you plan to implement PBR on the VPN client, its routing only depends on the destination.

It seems I can't get around manually setting up PBR on the VPN client in my case.
Thanks again, but then it's really only remotely related to OpenWrt.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.