Perfect.
Thanks!

GruensFroeschli,

Thank you again for your input.

1. When WAN is down, other inbound traffic is passing safely through OPT1. My loadbalancer is also working when WAN is down. Only VPN is not getting established.

2. Like you suggested, I removed the 2nd VPN server. And, I removed the "local xxx.xxx.xxx.xxx" from the custom options field for the remaining server. Now, I cannot connect on OPT1 interface even when WAN is up. With two servers, I was able to connect through OPT1 when WAN was up.

I must be missing something minor. Any help is greatly appreciated.

Thank you

I have locked myself out but I have OpenVPN access. I am just doing console to the box and option 14 tells me that sshd is enabled. But when I try to reach the box with ssh 192.168.1.1 I can't get any response.

I have checked and iptables -L doesn't exist either.

How can I get this router to accept my HTTPs and SSH requests?

What commands specifically?

Thanks

I got it to work.
It was a hardware issue. I won't be using any NICs with RealTech chips anymore.
I'm using an old Dell server with a pfsense installation (1 GHz processor 512 RAM), it has an integrated NIC and I added a PCI NIC. I think it was a used D-Link. I came to the conclusion after reviewing the settings many times that there was nothing wrong with them. I replaced the D-Link NIC with an old Linksys. The tunnel came up, but then all the LAN computers lost internet and couldn't even ping the pfsense box. After some more troubleshooting I moved the card to a new PCI slot and now everything works (for now).

Using the standard LAN rule with no failover produces the same result:

Pass Aug 18 11:02:58 NG0 xxx.xxx.xxx.xxx:1930 192.168.1.247:1194 TCP:S
Pass Aug 18 11:03:24 NG0 xxx.xxx.xxx.xxx:1933 192.168.1.247:1194 TCP:S
Pass Aug 18 11:03:50 NG0 xxx.xxx.xxx.xxx:1935 192.168.1.247:1194 TCP:S
Block Aug 18 11:04:31 LAN 192.168.1.247:1194 xxx.xxx.xxx.xxx:1930 TCP:S
Block Aug 18 11:04:58 LAN 192.168.1.247:1194 xxx.xxx.xxx.xxx:1933 TCP:S
Block Aug 18 11:05:24 LAN 192.168.1.247:1194 xxx.xxx.xxx.xxx:1935 TCP:S

Anybody? I'm trying to get my VPN on OPT1 interface to work. Should I setup the VPN servers on different ports? Will that help?

Ah!

So that's what i was missing.

I created the rule and reconnected the VPN and everything is working fine.

Thanks a lot cmb!

@dolbie2:

Site-to-Site followed exactly what the book said. In the book for the client configuration, the "Interface IP" is not specified but it is requred in pf1.2.3. How did you get past that?

There was an issue in the book, you might need to read errata #2 here:
http://www.reedmedia.net/books/pfsense/errata.html

its working.

Then double check that you also set TCP instead of UDP. The log seems to indicate it isn't making a connection at all.

You probably need a firewall rule on WAN to allow that traffic in as well.

No, you can't use 1194 for a port forward and for incoming OpenVPN connections.

Just run the pfSense instance on 1195 or any other port. It's not a big deal to adjust the clients to connect to the other port.

@jimp:

You can try adding a push entry again for that subnet, or adding a route statement for the subnet to the loc3 client config.

Yes it works!!!!! thanks Ive add a route to the loc3 client config

Hi,

no matter about this, i found an entry in the logs for openVPN saying 'VERIFY ERROR: depth=1, error=certificate is not yet valid:' and it turned out to be an invalid time setting.

Thanks

You need to setup the second OpenVPN instance manually, and on both of them, in the custom options put "local x.x.x.x;" where x.x.x.x is the CARP VIP on WAN.

It doesn't really matter how you try to reach the secondary, its routing won't find its way back to the master from a VPN like that.

A couple ways around it:
1. Put the master and slave OpenVPN instance on a separate subnet, and add a static route to the opposing router for that subnet
or
2. Assign the OpenVPN interface as an opt interface, and setup NAT so that the traffic coming from OpenVPN and going to the secondary router has NAT applies such that it leaves from a VIP on the LAN side, so the secondary will only see that the traffic is coming from a LAN host and it should be able to get back to the source then.

ah cool… i figured it out!

i think i just had to add the option 'local <wan carp="" ip="">' to the VPN's custom options in addition to the 'engine cryptodev'

i also added an AON rule before trying this, which didn't help, but maybe it was needed too?  i made the rule for source <new 24="" subnet="">:* to : with NAT address<wan carp="" ip=""></wan></new></wan>

I found out how to do this. When making a an OPEN VPN tunnel there is a box labeled "other options" simply put the router there

An example would be

Branch A 192.168.1.xxx
Branch B 192.168.2.xxx
Headquarters 10.0.0.1

If they each branch has a tunnel to headquartes it will automatically add the correct routes for them to talk. However, branch a and branch b will not be able to communicate. On Branch A's router in the "other options" box simply enter route 192.168.2.0 255.255.255.0 and that will send traffic for branch b through headquarters. Of course you have to change branch b's as well to read route 192.168.1.0 255.255.255.0 as soon as that is done it will immediately start passing traffic.