OpenVPN client issues

ptaylor

I am new to OpenVPN… Any help would be appreciated.

A small VoIP company named callwithus.com has a experimental service where you can VPN into them and perform VoIP calls through that tunnel. They primarily say this is mainly for getting around ISPs that block VoIP. My current ISP (AT&T in the BellSouth region) doesn't block VoIP (yet, at least), but I wouldn't mind having my conversations encrypted as they travel through the "tubes". :)

I've been able to get pfSense to establish a connection, and when I ping the VoIP server from the pfSense box itself, it pings just fine, but I can't ping it from my local network, where my Linksys SPA-2102 sits.

Is there some way to get pfSense to NAT out traffic destined to the private IP of the VoIP server?

Here's the relevant portion of route table on my pfSense box:
10.39.0.1/32 10.39.0.73 UGS 0 0 tun0
10.39.0.73 10.39.0.74 UH 1 0 tun0

From my local LAN, I can ping 10.39.0.74 (my pfSense's IP, I presume), but not .73 or .1 (the VoIP server).

Any ideas on what I need to do to get this to work?

Thanks,
Paul

Cry Havok

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.

ptaylor

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.)

Cry Havok

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?

ptaylor

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.

Cry Havok

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).

ptaylor

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.

Cry Havok

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.

ptaylor

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

Cry Havok

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.

ptaylor

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.