1
General Discussion / OpenVPN client - Gateway config invalid
« on: October 19, 2020, 01:46:20 pm »
Hi,
I have a routing issue (in another post) but I suspect the real issue is my openvpn client config.
I have an OpenVPN client configured in tun mode, udp, going through the WAN interface. My default gateway is the WAN interface, the vpn client is only there for some policy based routing.
What I've noticed is that the system doesn't seem to be considering the vpn interface as a WAN, so it's not generating outbound NAT rules and it's doesn't seem to be using reply-to (which is my real issue) on it.
When the connection gets established, a public IP is properly assigned to the interface, and a Gateway is created.
Below the two IPv4 black boxes (IP and Gateway) are covering the same exact IP.

That gateway has "dynamic" as the IP address, since I've ticked the "This interface does not require an intermediate system to act as a gateway" box in the interface config :

However in the Gateway "single" menu, the IP for the gateway is the interface's IP itself (instead of dynamic, seen when editing the gateway), hiding the IP since it's public :


There's also a route added by something to route the interface's IP to the loopback interface (the red square is the interface's IP, the black squares are just routes added by openvpn for the subnet and the first IP of the bloc) :

The result is that when trying to use the VPN, packets are routed through the loopback interface back at opnsense itself, instead of going through the VPN. So if I try to query any website for example, I'm getting my own HAProxy back since it's listening on ports 80 / 443 of the router.
One way to work around this I've found is to edit the gateway and use any other IP as a gateway, since openvpn doesn't actually require a gateway ip any value works there as long as it's not the interface's own IP (which seems to be the default value chosen when using dynamic).
That allows policy based routing to work, but that's obviously not a good way and still doesn't make it generate proper outbound NAT and reply-to rules so incoming connections aren't working.
Any ideas what I might be doing wrong ? I've been struggling with this for almost a week now.
Thanks
I have a routing issue (in another post) but I suspect the real issue is my openvpn client config.
I have an OpenVPN client configured in tun mode, udp, going through the WAN interface. My default gateway is the WAN interface, the vpn client is only there for some policy based routing.
What I've noticed is that the system doesn't seem to be considering the vpn interface as a WAN, so it's not generating outbound NAT rules and it's doesn't seem to be using reply-to (which is my real issue) on it.
When the connection gets established, a public IP is properly assigned to the interface, and a Gateway is created.
Below the two IPv4 black boxes (IP and Gateway) are covering the same exact IP.

That gateway has "dynamic" as the IP address, since I've ticked the "This interface does not require an intermediate system to act as a gateway" box in the interface config :

However in the Gateway "single" menu, the IP for the gateway is the interface's IP itself (instead of dynamic, seen when editing the gateway), hiding the IP since it's public :


There's also a route added by something to route the interface's IP to the loopback interface (the red square is the interface's IP, the black squares are just routes added by openvpn for the subnet and the first IP of the bloc) :

The result is that when trying to use the VPN, packets are routed through the loopback interface back at opnsense itself, instead of going through the VPN. So if I try to query any website for example, I'm getting my own HAProxy back since it's listening on ports 80 / 443 of the router.
One way to work around this I've found is to edit the gateway and use any other IP as a gateway, since openvpn doesn't actually require a gateway ip any value works there as long as it's not the interface's own IP (which seems to be the default value chosen when using dynamic).
That allows policy based routing to work, but that's obviously not a good way and still doesn't make it generate proper outbound NAT and reply-to rules so incoming connections aren't working.
Any ideas what I might be doing wrong ? I've been struggling with this for almost a week now.
Thanks