While the restricted to IP address would pretty much lock it down..  That sort of thing is really hard to do if this going to be a road warrior sort of connection.  If its for you to connect to your house from work that is another thing.

You should never share connection creds or certs, so yeah - if you have multiple users they should all have their own details.

+user auth would protect against if the certs and configuration were lost. Yup good thing.

Kind of given you would want auth the TLS - that is default I am pretty sure..

Auto gen is fine - unless you already had some keys you wanted to use from before, that sort of thing.

2048bit should be more than enough, but feel free to use 4096 if helps you sleep at night ;)

I personally just use BF-CBC 128 bit, it going to be a rare thing that someone would grab your packets and break the encryption..  I don't work for the dod, its my connection from road or at work to the home network.  Want some that is least cpu overhead.  If you have some hardware that can help with the encryption than use the alg that is best suited for that..  Other than I don't think it going to matter all that much.  Again if AES 256 helps you sleep then sure use that.

As what your doing with your CA.. Not sure what your asking.. You create a CA in pfsense, you then gen user certs using that CA.  Are you wanting to use some CA outside pfsense and have it gen your user certs?

my fault
thx for the help

i thoguht about that at the beginning but since im using nat for both 80 and 443 for my development box i cant test the OpenVPN on it.
i turned the SIP ALG back on , but for some reason it is still working.

honestly , im clueless, as long as it works, im an happy man.

Will IPsec let you do this?


Yes, the computer stays in the ordinary LAN with the others - it just has a fixed known IP that makes it easy to match in a rule.

create a rule for this special computer IP before the others LAN computers rules

Yes

If yes, what do you mean by "!LANnet". Is it a special net I have to create? If yes, where in the menus?

I mean, in the rule destination select LANnet from the dropdown list, and check the "not" checkbox.
You do not want traffic from "special LAN IP" that is going to the pfSense LAN itself to be forced out WAN_GW

And "gateway WAN_GW"? Should I create a Gateway somewhere in the menus?

In the advanced section of rule definition there is a "Gateway" row - open that up and pick WAN_GW. That will force the matching traffic out WAN.

Thanks jump.

Yep, that seems to be it.  I am running an ATOM Dual-Core 1.66GHz D510 CPU, and it can only muster about 7-8MB/sec with compression on the OpenVPN tunnel.  I can easily hit 10-11MB/sec using my Mac laptop (Quad-core i7).

Appreciate the reply.

Ok.  My CA expires many years earlier than my user certificates expire.  I'm assuming I'll have to reissue the certificates when my CA expires?

@Derelict:

Can you dictate the LAN addressing scheme for the remote sites?  If so, then pick something like 172.26.0.0/16.  Put that in the remote network in your server instance.  That will put a route in pfSense telling it to send all traffic for 172.26.0.0/16 into OpenVPN.

Then, in your client-specific overrides do something like this:

Site 1: "iroute 172.26.1.0 255.255.255.0"
Site 2: "iroute 172.26.2.0 255.255.255.0"
Site 3: "iroute 172.26.3.0 255.255.255.0"
Site 4: "iroute 172.26.4.0 255.255.255.0"
Site 5: "iroute 172.26.5.0 255.255.255.0"

iroutes are internal to OpenVPN so when OpenVPN receives traffic from pfSense for 172.26.3.12 it knows to send it out Site 3's tunnel.

Doing this allows you to leave the server instance alone when you add/move/change sites (changing the remote networks in the server instance restarts the server).  Changing client specific overrides doesn't.

I'm testing it now and it looks like it might be working correctly. I will test a bit more over the week before marking this resolved.
Supernetting… it's always a simple answer  :o Thanks for your reply

@Derelict:

Please see: https://forum.pfsense.org/index.php?topic=82732.msg473856#msg473856

Derelict, that was exactly what I needed. I knew I was over analyzing the problem. :) I setup the push routes and tested and it's working perfectly. My only issue right now is the huge range of ip networks AWS uses and it's always changing, but that's a different issue altogether. =)

Thanks for the clarification!

yes

@fatsailor:

We noticed some strange log messages today for about 5 hrs today. Then, the system crashed. The messages below repeated up until the crash. I've pasted a copy of the messages that continually repeated up until the crash.

I've confirmed no one was using nor attempting to use the OVPN service today. The messages combined with a crash (first crash in years) make my spidey senses tingle, and I'm hopeful someone can give me a clue what might have been happening.

Thanks, FS

Jan  5 14:50:59 pfSense php: rc.start_packages: Restarting/Starting all packages.
Jan  5 14:51:01 pfSense check_reload_status: updating dyndns WAN_DHCP
Jan  5 14:51:01 pfSense check_reload_status: Restarting ipsec tunnels
Jan  5 14:51:01 pfSense check_reload_status: Restarting OpenVPN tunnels/interfaces
Jan  5 14:51:03 pfSense php: rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_DHCP.
Jan  5 14:51:03 pfSense php: rc.openvpn: OpenVPN: Resync server1 OpenVPN Server
Jan  5 14:51:03 pfSense php: rc.dyndns.update: phpDynDNS (xxxx.dyndns.org): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
Jan  5 14:51:03 pfSense kernel: in6_purgeaddr: link-local all-nodesmulticast address deletion error
Jan  5 14:51:03 pfSense kernel: in6_purgeaddr: node-local all-nodesmulticast address deletion error
Jan  5 14:51:03 pfSense kernel: ovpns1: link state changed to DOWN
Jan  5 14:51:03 pfSense kernel: ovpns1: link state changed to UP
Jan  5 14:51:03 pfSense check_reload_status: rc.newwanip starting ovpns1
Jan  5 14:51:06 pfSense php: rc.newwanip: rc.newwanip: Informational is starting ovpns1.
Jan  5 14:51:06 pfSense php: rc.newwanip: rc.newwanip: on (IP address: 10.XXX.XXX.1) (interface: []) (real interface: ovpns1).
Jan  5 14:51:06 pfSense php: rc.newwanip: pfSense package system has detected an ip change  ->  10.XXX.XXX.1 … Restarting packages.
Jan  5 14:51:06 pfSense check_reload_status: Starting packages

This appears to be related to apinger. We turned off gateway monitoring, and that solved the problem.

Thank you all so much for your feedback!

This solution worked for me, i just added to the VPN under advanced configurtion on client side the subnet to be routed trought:

"route 192.168.10.0 255.255.255.0"

Tata!

Thanks!

@viragomann:

The recommended solution is to use different subnets on both sites, you know.

If you try to route the same subnet over VPN as is configured on physical interface the route will be ignored.
For workaround, you may add singular IPs you want access in the remote subnet to be routed over VPN instead of the hole subnet.
Remember that your VPN client host cannot access the same IPs in local network while it is connected to the VPN server.

Thanks! Worked perfectly.

More crap on this completely fresh reinstall of pfSense 2.1.5 (and even more crap new messages, which I have in a word document and will post later): attached pic.

I can not assess if this is related to this:

https://redmine.pfsense.org/issues/3894
https://forum.pfsense.org/index.php?topic=75502.0

I'm way to noob for that.

PIAVPN-weird.jpg
PIAVPN-weird.jpg_thumb
PIAVPN-weird2.jpg
PIAVPN-weird2.jpg_thumb
PIAVPN-weird3.jpg
PIAVPN-weird3.jpg_thumb

Is this help? ….

@jimp:

If your VPN client is OpenVPN and it receives its default route dynamically over that channel (e.g. "redirect-gateway def1" on the server) then you'll need to use "route-nopull" in the advanced options so that the client will ignore the default route information.

Hmm, Jim, if I do that I get:

]

| Jan 3 15:29:30 | openvpn[73188]: Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS]) |
| Jan 3 15:29:30 | openvpn[73188]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) |
| Jan 3 15:29:30 | openvpn[73188]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) |
| Jan 3 15:29:30 | openvpn[73188]: Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS]) |
| Jan 3 15:29:30 | openvpn[73188]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 209.222.18.222,dhcp-option DNS 209.222.18.218,ping 10,route 10.124.1.1,topology net30,ifconfig 10.124.1.6 10.124.1.5' |
| Jan 3 15:29:30 | openvpn[73188]: SENT CONTROL [Private Internet Access]: 'PUSH_REQUEST' (status=1) |
| Jan 3 15:29:28 | openvpn[73188]: [Private Internet Access] Peer Connection Initiated with [AF_INET]x.x.x.x.:1194 |
| Jan 3 15:29:28 | openvpn[73188]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA |
| Jan 3 15:29:28 | openvpn[73188]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication |
| Jan 3 15:29:28 | openvpn[73188]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key |
| Jan 3 15:29:28 | openvpn[73188]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication |
| Jan 3 15:29:28 | openvpn[73188]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key |
| Jan 3 15:29:28 | openvpn[73188]: VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=Private Internet Access, name=Private Internet Access, emailAddress=secure@privateinternetaccess.com[/t][/t][/t]

My settings are:

|

auth-user-pass /etc/openvpn-password.txt; ca /etc/ca.crt; verb 3; route-nopull;

What might this mean?

Thank you  ;D

If there is some computer behind the pfSense at the remote site, then you can install something like TeamViewer on it. That will also find its way out from behind private address space. Then you can TeamViewer to that computer (VM or whatever) and open a browser there to access pfSense webGUI even when the OpenVPN is down/off.