Inbound NAT to openvpn interface broken?
-
Hello there,
We're using OpenVPN to build a management cloud to our managed pfsense firewalls. We'd like to map
inbound connections to ports on this per-firewall management address to internal LAN servers on the
respective site. Something like this:mgmt_server => ovpn => [pfsense.openvpn.TCP.1443] => [pfsense.LAN.TCP.192.168.0.100.443]
We're using pfsense 2.0.1-RELEASE(i386), and it seems to generate a wrong rule base for this constellation:
NAT Inbound Redirects
rdr on openvpn proto tcp from $mgmt_server to any port 1443 -> 192.168.0.100 port 443
no nat on openvpn proto tcp from (openvpn) to /
nat on openvpn proto tcp from / to 192.168.0.100 port 1443 -> (openvpn)If I replace "OpenVPN" with "WAN" as "Interface" in the NAT:PortForward:Edit page, a correct rule base without
the extra 2 lines up there is generated (the extra 2 lines with "no nat" and "nat on" cause syntax errors from
pfctl).I can go into filter.inc and comment out the section that generates these extra lines, but I guess they're there
for a purpose, but I haven't figured out what purpose yet;)Am I trying to do something that is not supported, or is this a bug?
Cheers,
Markus -
you can't use destination "any" with port forwards on OpenVPN. It's been fixed for 2.1, and 2.0.2 if that is released.
-
Thanks for the fast reply! The reason for "Any" was simply that I wasn't able to chose "OpenVPN Address"
as the destination (possibly because OpenVPN is kind of a meta interface which could expand into multiple
addresses?). What would really be handy in the pf world is the equivalent of the "me" address of ipfw,
expanding dynamically to all current interface addresses. I'll check for workarounds in the meantime, like
adding explicit interfaces for that specific ovpn tunnel. Thanks again! -
If you gitsync to RELENG_2_0 it should work, though try that first on a test system to verify.
-
I think it might be dangerous to gitsync to 2.0.2 or 2.1 as both require a binary change last I knew. Something changed in the pfSense module on both that would break if it were not present.
It might be possible to grab just the one commit you want using the system patches package and apply it that way.
-
I'm currently setting up a pfsense "development server" to be able to do just that :)