OpenVPN client issues
-
The VoIP server needs to know where to route the traffic - ensure that either the pfSense host is the default gateway, or that it has a static route set up.
-
The problem is that I don't control the OpenVPN server. I don't think the service provider wants to support routing to remote subnets, as I'm sure that would severely complicate the configuration on their end.
To me, it seems that the problem would be solved if pfSense actually NATed the outbound traffic. That way the service provider doesn't have to worry with what networks are behind each remote client, or conflicts… (Multiple clients having a 192.168.0/24 network, for example.)
Any way to do this? I've tried using the WebGUI to set up an outbound NAT rule (though I haven't tried turning on Manual Outbound NAT yet). Perhaps pfSense doesn't NAT it automatically because it's a private network on the remote side? (10.)
-
ISTR you can apply any options to the OpenVPN interface, at least not under 1.2.
I assume that your own hosts have the pfSense host as their default gateway, or at least as a route for 10.39.0.0/24?
-
Yes - My hosts do have my pfSense machine as the default gateway.
I'm running 1.2 RC2. I don't see any indication of any new interfaces or anything like that after the OpenVPN connection comes up.
I've read in other posts that 1.2 hides all that from you and does it all behind the scenes.
I'm wondering if the default Automatic Outbound NAT only NATs for private IPs that go to public IPs. If that's the case, I may just need to disable Automatic Outbound NAT and add specific rules to perform NAT on both of my network interfaces, perhaps with a specific rule to NAT outbound requests to the 10.39.0.1 address of the VoIP server.
-
I suspect it may be that NAT isn't applied to the OpenVPN interface, at least under 1.2. You may need to raise a feature request to include NAT with the filtering support that's being worked upon for a post 1.2 release (1.3 or later).
-
Well, after looking at the code a bit, I figured out how to make it work.
I edited the /tmp/rules.debug file. At the end of the # Outbound NAT rules section, I added this single statement:
nat on tun0 from 192.168.111.0/24 to any -> (tun0)
The 192.168.111.0/24 segment is my local network.
After saving that file, I performed this command:
/sbin/pfctl -f /tmp/rules.debug
After that, I could ping the VoIP server's private IP Address (10.39.0.1) from my machine. I modified my Linksys SPA-2102 config to point to the 10.39.0.1 address instead of the normal SIP server address, the SPA rebooted, and when it completed the reboot the SIP connection was up and working as expected. I made a call to my cell phone and it worked just fine.
Now, this isn't a long term solution, as I'm sure that if I change any of my firewall rules, my modification to the /tmp/rules.debug file will be gone, but this was a good test.
I'm not sure how they would want to go about adding this sort of NAT feature into the interface… At least I know it works, though.
-
I'd suggest you raise a bug report (see the Contact page). From memory firewalling for OpenVPN is due for 1.3 (but search the forum for the actual details), I'd expect that adding NAT support at the time time should be relatively straightforward.
-
Ok - Ticket 1466 is open, per your suggestion.
I don't know if they are going to make it a checkbox to NAT the connection out, or just what, but I would have to say that if pfSense doesn't NAT out a client connection, the client connection would seem pretty useless to me. Of course, it's possible that I just don't know enough about OpenVPN.
Paul
-
I suppose it depends on your perspective. Most people who're using routing (tun) will be doing so in an environment where they have input to both ends of the network infrastructure. Certainly for me OpenVPN works like a charm and does exactly what I want it to.
-
I agree that in situations where you control both sides, this isn't an issue at all, and after giving it a bit of thought, I imagine that this is probably the vast majority of cases with OpenVPN.
