@phil.davis:

I just noticed that some of the rules you were trying had protocol TCP selected. So they were not effective, because your OpenVPN (as is normal and best practice) is using UDP.
That is a bit of a trick when making new rules - the protocol field defaults to TCP, rather than "any".

Jesus. How couldn't I notice. You're right and it's so obvious but somehow I managed to ignore that field when checking the rules. Should've taken a closer look at pfBlocker's rule aswell:  **IPv4 ***

Nevertheless I posted this issue at OpenVPN forum also because I'd like to know what exactly this IP was doing? Does the log entry mean, the IP connected to my OpenVPN but without correct auth. data? Or is it just about the ta.key as I've read somewhere when searching for this message.

I don't understand - "push "route …"" is probably something you put in the advanced box of the server. When the client connects, the server pushes the route to the client in real-time, effectively telling the client that the server is the route to the specified subnet. There will be nothing special in the client config.

But if you want the client to push a route to the server (i.e. client tell server about a subnet reachable through the client) then that is different.

What are you trying to achieve? In which direction?

Also, at the server end, you do not need to push route - just put all the subnets reachable through the server into the Local Network/s field.

Can someone confirm the question posed by mtisza:

Assume no clients from the client specific override section are currently connected, and then a user (non-override type) connects to the VPN, what IP will they be assigned?  I'm hoping the answer is that pfsense will definitely know that 4, 8 and 12 are "reserved" for the overrides and MUST not be used.

Is that how pfSense behaves?

Thanks!

I second that emotion!

I've been playing around with OTP using various fobs/clients, including "Google Authenticator".  Would be great to have that!

Ok, so starting OpenVPN in admin mode does let it add a route to the table:

IPv4 Route Table =========================================================================== Active Routes: Network Destination        Netmask          Gateway      Interface  Metric           0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.10    10         127.0.0.0        255.0.0.0        On-link        127.0.0.1    306         127.0.0.1  255.255.255.255        On-link        127.0.0.1    306   127.255.255.255  255.255.255.255        On-link        127.0.0.1    306       192.168.0.0    255.255.255.0        On-link      192.168.0.10    266     192.168.0.10  255.255.255.255        On-link      192.168.0.10    266     192.168.0.255  255.255.255.255        On-link      192.168.0.10    266       192.168.1.0    255.255.255.0    192.168.10.5    192.168.10.6    30     192.168.10.1  255.255.255.255    192.168.10.5    192.168.10.6    30     192.168.10.4  255.255.255.252        On-link      192.168.10.6    286     192.168.10.6  255.255.255.255        On-link      192.168.10.6    286     192.168.10.7  255.255.255.255        On-link      192.168.10.6    286         224.0.0.0        240.0.0.0        On-link        127.0.0.1    306         224.0.0.0        240.0.0.0        On-link      192.168.0.10    266         224.0.0.0        240.0.0.0        On-link      192.168.10.6    286   255.255.255.255  255.255.255.255        On-link        127.0.0.1    306   255.255.255.255  255.255.255.255        On-link      192.168.0.10    266   255.255.255.255  255.255.255.255        On-link      192.168.10.6    286 =========================================================================== Persistent Routes:   Network Address          Netmask  Gateway Address  Metric   255.255.255.255  255.255.255.255        On-link        1         224.0.0.0        240.0.0.0        On-link        1 ===========================================================================

Pinging 192.168.10.1 or 192.168.1.1 both still time out.

Interesting enough, it managed to connect after the trial was over and it charged my card. Strange. Support couldn't explain that one either, but maybe it was just some sort of fluke.

However, when the OpenVPN connection sets up and connects to Vyprvpn, I no longer can access anything out on the Internet on any connected machine. I don't have any rule sets for the whole LAN segment to route out via Vyprvpn, etc. If I disable it, then I can get back out to the Internet.

Also looks like I keep getting messages of:

Mar 1 20:24:25 openvpn[41699]: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #18477269 / time = (1393696330) Sat Mar 1 12:52:10 2014 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Any ideas what that could be?

you can 1:1 NAT your home-lan to a "virtual" subnet over your vpn.

for example:

hotspot_your_ip = 10.0.0.200
lan_host_you_wish_to_reach = 10.0.0.100    <<–- routing issue
1:1 NAT your home_lan to 172.18.1.0/24  -------- from hotspot_your_ip you'd then connect to to 172.16.1.100 | and the NAT would have you end up on 10.0.0.100    <<--- routing issue "solved"

i have a couple of sites where changing the lan-subnets is a ton of work (static ip's). I've used this method to circumvent possible routing issues

On 2.1 and later you just put a comma-separated list of subnets in "Local Network/s" and then the OpenVPN server tell the client about routes to all those. There is no need to use the Advanced box.

;D
Will check that out - thanks

all right, that sounds great - thank you guys!

Thanks for the info.
We arnt using multi-WAN link via PFSence, we another method for multi-WAN.
The three hosts are on 2.0.1 rather than 2.1 as a test system i did an upgrade to 2.1 on ended up breaking half the packages and needed a reinstall! :(
2.0.1 is working for now, "if it aint broke dont fix it" :p

@tomelgato:

Feedback: Works perfectly, thanks a lot!

Good to know it works for others - thanks for the feedback.

The selection of WAN1 or WAN2 in priority order is done in pfSense by making a gateway group with the required WANs listed in priority order, then telling the OpenVPN server/client to use that gateway group as its "interface". pfSense does the rest underneath to bind the OpenVPN to the "best" WANin the gateway group as conditions change. So you don't need OSPF for that.
What you say about ISPs and reach-ability is true, and that is a failure mode that could benefit from having OSPF. I have had times when SiteA cannot reach SiteB, but SiteA can reach SiteC and SiteC can reach SiteB, so there is a possible path. So yes, OSPF should learn and route around that.

@phil.davis:

Would it be possible to make the defaults configurable? Especially Host Name Resolution is critical. I forgot a couple of times to change it before exporting…
I have this brain trouble also - I added a feature request to RedMine - https://redmine.pfsense.org/issues/3478
If the computer can remember for me, that is much better than relying on my memory or a separate doc.

It may be possible but it would be quite a significant effort, development-wise. If someone does the work and submits a pull request, we'll consider it, but I don't see it happening unless the code shows up.