OpenVPN server bind to any interface will respond on wrong interface
-
openvpn which get connect on em1 will send packets on em2 (default route) even if having reply-to rules.
If I bind openvpn server to a single interface or group it works.pass in quick on em1 reply-to (em1 62.159.188.153) inet proto udp from any to any port 1194:1196 keep state label "USER_RULE: OVPN Server"
pass in quick on em2 reply-to (em2 109.192.176.1) inet proto udp from any to any port 1194:1196 keep state label "USER_RULE: OVPN Server"
pass in quick on pppoe0 reply-to (pppoe0 217.0.117.215) inet proto udp from any to any port 1194:1196 keep state label "USER_RULE: OVPN Server" -
Not sure if you are running OpenVPN server or client (you say server). I had a similar problem (see: http://forum.pfsense.org/index.php/topic,63268.msg341915.html#msg341915) The .pdf in the second post helped a lot. Basically, I had to configure the gateways for the service to work nicely.
I also have an OpenVPN server on the same box. That worked "out of the box".
You are better to configure the routes in the OpenVPN dialogues (either in the IPv4 Remote Network/s box or in the Advanced Configuration with route commands if the remote networks box is too restrictive for what you want to do)
-
Another possibility could be to make OpenVPN server listen on the LAN interface and then do PortForwarding from every WAN to the LAN.
-
Why can I choose any interface if it's not working?
-
What you describe is how UDP works when attached to "any" interface. Reply-to doesn't help when the UDP program (OpenVPN in this case) sources the traffic from the wrong IP. It will use the IP "closest" to the client, according to the routing table, which tends to be the default route. That's why binding to a specific interface is preferable.
On 2.0.x, I would bind a server to LAN and use port forwards to get traffic in to the service over WAN/WAN2.
On 2.1, I would either bind to localhost and use port forwards, or (less preferable on the server side), use a gateway group for an interface.
The "any" interface selection is still there because that's what 1.2.x used and there wasn't a good way to upgrade and keep people's settings as they were otherwise in such cases. There are still times when "any" works OK and does what people want, but those cases are much more rare compared to when a specific interface binding is warranted.
-
On 2.1, if you use a gateway group on the server side, then the server will listen only on the first highest tier member of the gateway group that is up. If you have a primary link that you want used normally, and just want to fail over the server to a backup when primary is down, and fail back when it primary comes up again, then use a gateway group. (And you would need some way for the clients to know where to failover - have a Dynamic DNS also on the gateway group, or have the clients configured to first try the primary address then the backup address).
If you just want clients to come in however on multiple links, then the port forwarding thing works - the server can be effectively listening to incoming on multiple port-forwarded WANs. Then you can design whatever scheme you like for the client configs to try the various available addresses in some order, or to offer a DNS name that has multiple IPs in a round robin or…
-
But why didn't reply-to rules not work?
Ping works from outside on all interfaces. Without reply-to ping works only at the interface with the default route.
The OpenVPN rule matches. If I enable logging for this rule I get log entries.Is there an other rule which will catch the reply from openvpn server and pfsense ignore the state of the udp connection?
Is the an option for pfctl -s state which shows the matching rule? -
But why didn't reply-to rules not work?
Ping works from outside on all interfaces. Without reply-to ping works only at the interface with the default route.
The OpenVPN rule matches. If I enable logging for this rule I get log entries.I already answered that above:
@jimp:What you describe is how UDP works when attached to "any" interface. Reply-to doesn't help when the UDP program (OpenVPN in this case) sources the traffic from the wrong IP. It will use the IP "closest" to the client, according to the routing table, which tends to be the default route. That's why binding to a specific interface is preferable.
pf cannot affect what the program does when sourcing traffic. To pf, that is a new flow/state, not part of the previous connection.
Is there an other rule which will catch the reply from openvpn server and pfsense ignore the state of the udp connection?
Is the an option for pfctl -s state which shows the matching rule?No. Bind to one interface, use port forwards.
-
Now I understand. Multihome didn't work with freebsd and udp.
Is freebsd with all it's side effects still the right os for a multi-wan router?
-
Yes, that is not specific to FreeBSD. It's an issue with UDP in general. UDP is connectionless/stateless.
-
There should be a mechanism for udp sockets like nat uses to choose the right source ip or the application can overwrite the source ip.
For linux there is a multihome option for openvpn which uses source ip routing.
