So on the HO firewall I've activated AON and created a manual rule to NAT my remote subnet as stated in different post but it's still a no go. (see attached jpeg)
I can reach internal web server from Remote site but still no Internet.
Running on the last pfsense distro 2.0.1-RELEASE (i386)

Anyone for any help please?

AON_HO.jpg
AON_HO.jpg_thumb

Remove the package, run a firmware update.

tap isn't really properly fixed until 2.1, the patch was just a half-hearted attempt to get it working on 2.0.x, but it doesn't fix everything for everyone.

If you really want tap, use 2.1-BETA

In that case say your fqdn is server.something.tld  place something.tld in "DNS-Domainname," pfsense LAN IP in "DNS-Server" and make sure you can resolve fqdn through pfsense (place it in Services > DNS Resolver) and you should be able to open up \server as well.

Disable nmb service, remove WINS from OpenVPN and don't forget to reconnect.

That shows you can't connect to the server's IP on TCP 1194. It's generally preferable to use UDP for performance reasons, but that aside, the most common causes of that:

no firewall rule allowing TCP 1194 to the server IP on the server side. network the client is behind doesn't allow TCP 1194 outbound wrong server IP or port

This is fixed with help form PiBa-NL in IRC.

Strange route was on the client in remote network causing all sorts of trouble. Cleared the route and things started working again.

You just need to export the windows CA cert and key and then import that into PFSense. Then set the OpenVPN server to use that CA. You can create a server cert using that CA as well. Then create the client certs with the windows CA tool, and your PF sense OpenVPN will then recognize those certs because it has the same CA cert.

Do the same thing with your CRL as you do for the CA. You will need to manually update the CRL on the pfsense box each time a cert is revoked.

You wont really be able to use the client export utility, because the client certs wont exist on the pfsense box (just the CA, and server cert). But it is pretty easy to build up a little openvpn package manually. In your domain you can make the msi for openvpn install and then have their logon script copy their config, plus your global tls-auth key to the client. Then you can use windows tools to export their client cert into a crt and key file so openvpn can use it. I am sure there are some command line utilities to do that. If you name their client cert and key files the same for every user then everyone can share the exact same config file, and the only thing that would be different per client machine is their certs.

Also, you have some problems in the screenshots.
-Your tunnel network is 'inside' your local network subnet. 192.168.17.0/24 is inside 192.168.0.0/16 I generally use 172 addresses for tunnel networks as they are rarely ever used for other things, and it makes them a bit obvious.
-Also, you probably want to turn on NetBIOS over TCP/IP, otherwise you will not be able to access windows file shares and printers and such. Set the IP it asks for to one of your AD servers, and start with h-node, but you may want to experiment with the other node settings if h-node does not work well. In an AD environment, it should work pretty good though.

Phil,

It turns out i had a weird outbound nat rule that was screwing everything up. removed that and everything is good to go. thanks for the help :O)

Many https sites have trouble with loadbalancing. For security reasons they assume that when a session is suddenly change source ip, it must be "hacked".

it is allways a good idea to create a seperate gateway group in failover-mode for all https traffic, this will reduce trouble with financial transactions

The redirect-gateway def1 does not only add the 0.0.0.0/1 it also adds the 128.0.0.0/1 plus the x.x.x.74/32 pointing to your local gateway.

The route commands are to be used in a peer-to-peer connection and not in a PKI.

From your description i don't really see what your goal is.
If it is to simply have multiple VPN tunnels up and use failover pools between them:
In such a setup your routing table isn't relevant anyway.
You define gateways and traffic is forced to them directly, bypassing the routing table.

FYI- on 2.1 if you assign the openvpn interface and add a pass rule on its tab, that rule will get reply-to added so that the return traffic will flow back the right way without needing the extra NAT to mask the source address.

2.0.2 should be out in the near future (had a few things hold up the release… still trying to get it out) There are test images out there for 2.0.2, linked in a thread on the forum here.

2.1 will be out in the next few months if all goes well, realistically close to the start of the year, maybe later.

@phil.davis:

The DMZ OpenVPN Server end will need rules to allow traffic in from 172.242.242.0/24 - if the existing pass rules on OpenVPN are not wide enough already, then add one.
In the DMS OpenVPN Server Advanced box, you can just tell it routes, no need to "push" them from the other end. e.g.

route 172.242.242.0 255.255.255.0

This tells the server end that the OpenVPN link is the next hop for reaching 172.242.242.0/24
From your description, I think that is all that is needed - allow the packets into the DMZ pfSense from across the OpenVPN, then give the DMZ pfSense knowledge about how to route the responses back.

That did the trick!

thanks  ;D

@jimp:

I try to hand-deliver VPN configurations where possible, or at least put them into a directory that can only be accessed via something more secure (typically an SCP host set for key-only auth, etc).

You're right and I eventually came to the same conclusion. 
So I'm sending them a 15+ char disposable pass in an encrypted email that's good for a 3 hour download window from a server that publishes to rotating ports.

I've also been using pfBlocker to restrict server access to our local ISPs.

It's not a key but it's something.

When I stop OpenVPN service this root disappears.

I've tried to reboot it. Also I've tried to re-configure clean installation using i386 and amd64 2.0.1 releases.
Similar logs received.
I suppose that something has been changed on provider's side and I don't know what to change on my side to make it work.  :-\

The other thing to check is that the devices that do not respond (e.g. 192.168.0.115) do have their default gateway set to your pfSense LAN address (192.168.0.2). Devices like WiFi APs etc often get setup with their IP address/netmask on the LAN, but no-one enters a default gateway for them (or their default gateway is set to some old router address from years ago…). So they talk happily on the LAN, but can't get outside.