Thank you again for your help  :P

I've made the changes recommended here, and it appears to be working correctly now (although PFS didn't remember the block rule for my local LAN, which I added to the OpenVPN-rules in the firewall; very strange, I had to enter the rule 4 times  ???).

Well, it has to be working anyway, since her majesty has left the house and is on her way to the airport, so I can't do anything about it anymore right now. And I am on my way to the kitchen, to learn how to prepare food for myself   :D

Thank you again for your help   ;D

(And yes, Windows firewall = yuck. As is Windows. But she wouldn't allow me to put PC-BSD on the laptop :-).

Ok got OpenVPN working I had to add in the OpenVPN configuration also a Tunnel Network for IPv6.

Thank for you help doktornotor and I have used the your prefered manual for the configuration not the one with the bridges.

Kind regards
Simon

OpenVPN client - ics-openvpn-0.5.39.apk - does not work in Android v4.0.4 connecting to pfSense v2.0.3 + Client Export Package + OpenVPN Patch Package
Works from WinXP.

The Android OpenVPN client gets disconnected at once with the following error message for both the non-default port of 33121 and the default one of 1194.

Unfortunately, OpenVPN for Android has stopped.

The FEAT VPN App for Android works though - ics-2013-01-23.apk.

openvpn_pfs_203_android404.png
openvpn_pfs_203_android404.png_thumb
Android_FEAT_VPN_withpfsense203.png
Android_FEAT_VPN_withpfsense203.png_thumb

Hmmmm.  I would do a few things differently.

I would create 1 openvpn thread on 10.23.10.0/24 and the second on 10.23.11.0/24 or so…  (just to get away from the 192.168s)
Then I would check my firewall rules to be sure the rules had been generated properly to PASS those subnets to ANY.  Check the subnets match above.
Then I would create the outbound NAT rules to allow the LAN and for both openvpn subnets. (I stopped using auto outbound NAT on WAN).

Now try it on manual.  Be warned that manual outbound NAT is picky.  Has to be done correctly, but it never leaves me wondering "what went wrong"?

If that doesn't work, having a snapshot of you NAT rules, Firewall rules, Outbound NAT rules, and openvpn config would help people help you.

P.S.  The reason I quit using Automatic Outbound NAT is because it kept rewriting SIP packets and was killing my servers.
And I'm a control freak...  Thus the pfsense.

Phil,

1. The pfSense interfaces are subnets carved out of the supernet; we have a lot of subnets behind each firewall.
  2. I'm not sure why there is a /29 on the existing OpenVPN tunnel, I will change it to a /30 in the future.

Additionally, my issue is now resolved.  The issue was that the server side of the tunnel (Site B) was not properly routing the traffic, even though the proper routes were there.  Rebooting the pfSense box appears to have fixed it.  On that note, I'm working on another tunnel, and I've run into the same issue, is there ANY way to restart specific components of pfSense that would kick-start the routing system without having to completely reboot my production firewall?

-ct

Not on 2.0.x, but on 2.1 I have added a command-line management script for managing services that can control OpenVPN. I'm not sure if it would pull back to 2.0.3 OK, I never tried it.

But if you're on 2.1 you can just run, for example:

Now I understand,
Yellow router has a WAN IP in Green network - e.g. 192.168.0.2
Blue router has a WAN IP in Red network - e.g. 192.168.1.2
Devices in Green and Red can already talk to each other, because the Green and Red routers have a VPN link across the internet.
To directly route from Yellow, across Green and Red, to Blue, you need access to Green and Red to add routes to them.
But, you can setup an OpenVPN site-to-site link from Yellow WAN IP 192.168.0.2 to Blue WAN IP 192.168.1.2 without changing Green or Red routers. Then follow the information in the other post I linked to, and it it should work.

Well, you have posted in the OpenVPN section, so I guess you will get somewhat biased opinions :)
For what it's worth, run pfSense on something at the internet interface, to be your router, firewall and OpenVPN server. There are OpenVPN clients for plenty of OS that are known to work. For Windows, pfSense can download you a client install exe that has the necessary application and configs all bundled up to go.

Also, if your private subnet is something common like 192.168.1.0/24 then change it now to something less common, so you don't get hassles when clients connect from somewhere that is already 192.168.1.0/24

Sure, push the vlan subnet through the advanced config and block what you want thru firewall rules on the openvpn tab.

Or you can simply tell openvpn that your "Local Network" is the vlan and it will only route that subnet thru the tunnel.

Your server config screen cap is kinda low res… can't read anything once you zoom in... can you post the server1.conf?

Also need to see the firewall rules from your OpenVPN tab.

@Fr0ntSight:

It is a 64bit machine

64bit machine != 64bit OS.

@tjgertge:

I'm having the same issue as well.  Have you found any resolution?

The resolution is to NOT try to install 64bit applications on 32bit OS.

1. Use "tun", that is for routing between different subnets at each site. "tap" is for bridging, when you want the same subnet everywhere and broadcast traffic to go across the OpenVPN and be seen everywhere.
2. You don't need to change any NAT. NAT is not needed between the subnets on your private intranet - they can route happily to each other across the secure OpenVPN links. The internet traffic at each office goes straight out the office WAN/s and the automatic outbound NAT takes care of it. (If, one day, you want to send internet traffic from a branch office across the OpenVPN to the main office, then out to the internet, then you have to mess with manual NAT)
3. Each office has a LAN subnet, and each OpenVPN link is a subnet - this is the "Tunnel Subnet". Technically the tunnel subnet for a single site-to-site connection can be just 4 addresses (a "/30"). But it is much easier on the brain to give it a "/24". e.g.
Main Office - 10.77.0.0/24
Branch 1 - 10.77.1.0/24
Branch 2 - 10.77.2.0/24
OpenVPN Tunnel Main to Branch 1 - 10.78.1.0/24
OpenVPN Tunnel Main to Branch 2 - 10.78.2.0/24

Make up 10.n.n.0/24 numbers to your liking.

4. The OpenVPN client keeps trying every 60 seconds, forever until it gets a response. In my experience, OpenVPN is very good at reestablishing itself after 1 end has gone away and come back again.
If you need Branch 1 and Branch 2 to talk to each other, then make another OpenVPN site-to-site between the 2. Then if Main office is down, branch 1 and 2 can still communicate. Note: It is possible to route from branch 1 to branch 2 via main office, but in this 3 office triangle it is simple to add the 3rd OpenVPN link.

Ok, site to site, PFsense on both ends, forget the iroute.  I don't see a route to the 192.168.10.x/24 network on your server…. that's why you can't get to the client-side.  Although, I do see a route to the 192.168.194.0/24 network.... which looks like the LAN on the client-side.... are you sure the client is on the 192.168.10.0/24 network?  Might want to double check... cause it doesn't look like it.

Post your server1.conf and client1.conf.

On the client-side, it looks like you're double NATing, so you'll have to either remove it or keep your static route in place (someone correct me if I'm wrong)

"TLS key negotiation failed to occur within 60 seconds" just means that it can't reach the server, or the server rejected it.

Check the server log for OpenVPN and you may find the answer, or at least more info we can use to help. If that log shows nothing, then it is either a connectivity issue or a firewall rule issue.

@phil.davis:

On his end, assign an interface to the OpenVPN site-to-site link. Leave the IPv4 type as "none" (the system will organise the existing IP of the OpenVPN link…). Then a gateway should appear that goes to the other end of the site-to-site link. Add a firewall rile on his LAN selecting the relevant source IP, destination all, and in the advanced section select the gateway for the site-to-site link.
At your end you probably need to:
a) make sure the OpenVPN link has a pass rule allowing the special source IP, destination any.
b) NAT the traffic from him heading to the internet (automatic outbound NAT is only going to do it for traffic from your LAN to WAN)
Others, what have I forgotten?

This did the trick! Makes sense now. I think I was making it out to be a little more complex than it turned out to be. Thanks for the info!

galgier,
v1.5.5 is a version of OpenVPN Access Server, which PFsense does not use.

Glad it's working.  It looks like you're using split tunnel, so my thought was it had to be on the client end, but you're also double NATing and using port 443 instead of 1194… that probably has something to do with it.

Also, I'm curious to know why you're pushing out google DNS with a split tunnel deployment.