@viragomann said in OpenVPN Behind NAT ISP Router:

Did you the packets capture on WAN as requested?
If you see nothing there the router doesn't forward the traffic properly.
Don't set any filter to ensure you see all traffic arriving on WAN!
Did you update the MAC in the port mapping to that one of pfSense WAN interface?

Yes, I did on the WAN Interface.
I see traffic only when I try from local network using the public IP. If I delete the port-forwarding I see nothing even if I try from the local network using the public IP.
I didn't set any Block rules on the WAN Interface to test it.
The first step I did is to update the MAC address in the port-forwarding on ISP router.

@laplacian said in second OpenVPN server does not route:

Okay, just did that. Now neither one of my servers work. I have 1 allow any rule on the OpenVPN server 1 interface, 1 allow any rule on the server 1 interface, and no rules on the auto-generated OpenVPN tab.

@Gertjan
Oops, I spoke too soon. Netgate documentation says you have to restart the servers after creating new interfaces. When I did that, I'm back to square 1: server 1 works as expected and server 2 (port 1195) does not seem to route.

I also did a diff of the server configs. The only things that differ are the port numbers and the interface IPs:
0d754854-45e5-4a95-91aa-42eb5e777838-image.png

The routing seems normal:
ae475855-da58-4802-8e8a-e0f19bd11152-image.png

Thanks for the tips so far, but is there anything else I can audit or compare between the two? This is really strange (and frustrating...)

@chris1284
No not all rules on all interface, but only interfaces which are included in the OpenVPN group. The group only includes OpenVPN instances, you cannot modify it.
Rules on an interface group even on OpenVPN tab have prio over rules on the OpenVPN instances.
You should consider this, when you have rules on this tab.

@cswroe Thanks for reply, pushed into right direction
It works now. I have deleted the old konfig and started again without wizzard.
I think the main problem was the firewall rule setup. In the first setup there where some rules missing. also i switched to ssl/tls + user auth.

I think my mistake was to think that "openvpn client" means one config for each client that i wish to connect to MY OpenVPN.

Now it is running and after some reading into dns in openvpn, this is also running.
I think now it is configured good
state.png

@viragomann
Thnx again, my N5105 is on the way. ill see what would it can do:)
regards

Thanks all, update went well, VPN and other configurations appear to have been preserved.

Later I will try an install from the file to see if I can get zfs up. I would really like to have the ability to use different boot environments, but that is a separate story for later.

Again, thanks all.

@jimp
yep. I missed it. Thanks.

@frodet You have to fix your client configuration if you switch your server to use DCO.

DCO automatically comes with a few drawbacks from the OpenVPN team (that are stated in the blog post Netgate published to DCO and the docu). E.g. AES-GCM is the only supported cipher (besides CHACHA20), compression is not available and mtu/mssfix/fragmentation settings aren't available.

As your client sends AES-CBC that won't work, the other lines are most likely follow ups of the wrong cipher setting.

Cheers

I changed "data-ciphers" following this information: link

Reasonable?

@rcoleman-netgate Thank you!

FYI- There are a couple different ways that they can show up UNDEF:

If something probes the server port without actually speaking the OpenVPN protocol or otherwise doesn't complete authentication If you use User Auth only (no SSL/TLS) and do not have "Username as common name" enabled

The latter is normal/expected and OK. You probably want to enable that option in that case anyhow, it really only has benefit when using SSL/TLS+User Auth and each auth user can have multiple different certificates.

The former is a bit trickier since you kind of have to have OpenVPN open to the world to accept remote access VPN connections, but the good news is as long as you have a TLS key on the tunnel (Either TLS auth or TLS encryption+auth) it's a non-issue. It won't matter if anything probes the VPN port because without the TLS key the packets will be rejected without even performing a full TLS exchange.

Everyone should have a TLS key on their OpenVPN servers anyhow not only for the authentication protection, but also because it is an extra authentication factor ("something you have", similar to a cert) and it has also been proven effective at protecting the server against OpenSSL exploits like Heartbleed in the past.

@viragomann

Thanks for answering. Yes, it is a Remote Access configuration, not S2S. I forgot to include that I am also utilizing RADIUS-controlled ACLs, so the user connecting is getting a specific ACL configuration. It seems that when the RADIUS server returns ACLs, no other rules are evaluated which are locally configured on the firewall. And indeed, no rule was matched while I tested. As soon as I removed the ACL coming from the RADIUS server, they started to match, and packets started to get out the correct WAN interface. I tested this with an assigned interface for the instance, but I suppose it will work without it too.

Now the question is: will it be possible to achieve this while preserving the ACLs from the RADIUS server or these are mutually exclusive? I don't think the RADIUS server can pass a rule for policy routing, so it's just a packet filter. If it is not possible, maybe just get rid of the RADIUS ACLs, create another instance of OpenVPN, assign it to an interface and do the filtering there? The idea is to have different ACLs for different user groups.

@jknott thanks for your help

@sandsjh
I'm not familiar with Tailscale. But I don't think, that it's the same reason. As you wrote, your machines are able to access the internet, but they go out with your WAN IP instead of the VPN endpoint. So it's obviously a routing issue.

The OpenVPN server in this topic pushes the default route to you. You can check that out in pfSense routing table. If the route is not pushed by the server you can state it in the client settings anyway to direct all traffic to the VPN server.
There might be a similar option in Tailscale.

Is see you stated "--accept-routes", but possibly the server doesn't send ones.
Look for an option to actively set routes on the client.
If that is done you maybe also need an outbound NAT, if that isn't done automatically in Tailscale.

Yes, 1.6_6 also fixed the problem for me as well.