Nothing to do directly with this thread, but OpenVPN development itself continues after a long stop. New RC has been released. A final version (2.1) when it will be ready :)

Regards

Asenkevitch,

I too am a bit scared of a hole as I see it in pfsenses OpenVPN implementation. If my mobile user loses control of his laptop anyone with access to that machine can connect to my network. Yes, I can revoke the keys, but what if my user cant/doesnt tell me for several days. Also the adminsitration overhead of all those certificates gets cumbersome when you start getting beyond 10-15 users.

You want filtering which could add some protection to certain boxes segments, but what I would like is user authentication via RADIUS. Without the right credentials, nobody gets in. In fact they get locked out. That said,  I have seen several posts of people who have done some twists and turns to get RADIUS, and PAM working, however we use the embedded version which has no package support. So my question is how can an enterprise using pfsense on the embedded platform sleep easy knowing they have certificates and authentication protecting the OpenVPN dooway??

I would love to help any bounty propsing for out of the box OpenVPN/RADIUS on the embedded platform if anyone knows of one.

Thanks,

Pedro

Right

Thank you for that info Gruens, that is exactly the question I was meaning to ask.

Get a bigger UPS ;D

solved, i have 2 gateways in both networks, so i have to add the routes to the non-pfsense gateways :-/

any thing????

am i the only one that has the problem?

Well it seems to work sometimes. It seems like it I coming in one and going out the other. Normally I have to kind of play with the connection to get it to work. Any thoughts?

1.2RC3.

The boxes are ALIX WRAP systems and they're in remote locations so I'm not able to upgrade to 1.2RC4.

Hi again,

Here are the IP4 routes from netstat -nrW:

pfsense A
Destination        Gateway            Flags    Refs      Use    Mtu    Netif Expire
default            194.XXX.XXX.253    UGS        0  168620  1500      vr1
10.0.20/24        10.0.20.2          UGS        0    20300  1500    tun0
10.0.20.2          10.0.20.1          UH          1        0  1500    tun0
10.0.30.2          10.0.30.1          UH          1        0  1500    tun1
127.0.0.1          127.0.0.1          UH          0        1  16384      lo0
192.168.0          10.0.30.2          UGS        0  107810  1500    tun1
192.168.254        link#1            UC          0        0  1500      vr0
192.168.254.204    00:0d:93:9d:fd:3a  UHLW        1      392  1500      vr0    702
192.168.254.240    00:16:cb:a9:e8:67  UHLW        1      43  1500      vr0    437
194.XXX.XXX.224/27  link#2            UC          0        0  1500      vr1
194.XXX.XXX.225    00:XX:XX:XX:XX:de  UHLW        1      19  1500      vr1    93
194.XXX.XXX.227    00:XX:XX:XX:XX:de  UHLW        1        0  1500      vr1    98
194.XXX.XXX.254    00:XX:XX:XX:XX:0b  UHLW        2    5955  1500      vr1  1189

pfSense B
Destination        Gateway            Flags    Refs      Use    Mtu    Netif Expire
default            220.XXX.XXX.241      UGS        0    81874  1500      vr1
127.0.0.1          127.0.0.1          UH          0        0  16384      lo0
192.168.0          link#1            UC          0        0  1500      vr0
192.168.0.1        192.168.0.2        UH          1        0  1500    tun0
192.168.0.193      00:16:36:53:c8:64  UHLW        1    5963  1500      vr0  1187
192.168.0.232      00:19:d1:61:a3:aa  UHLW        1    10363  1500      vr0    939
192.168.0.233      00:14:2a:8a:1e:42  UHLW        1    7065  1500      vr0  1149
192.168.0.234      00:14:85:5e:9a:de  UHLW        1    6628  1500      vr0  1144
192.168.0.236      00:08:a1:92:31:94  UHLW        1    1826  1500      vr0  1140
192.168.0.237      00:11:5b:f4:1d:ff  UHLW        1    1010  1500      vr0  1200
192.168.0.238      00:16:76:c5:51:e0  UHLW        1    4272  1500      vr0  1145
192.168.0.239      00:19:d1:ee:1e:6a  UHLW        1    2951  1500      vr0  1179
192.168.0.240      00:14:2a:8b:7b:b1  UHLW        1    8819  1500      vr0  1188
192.168.0.241      00:11:5b:f4:26:4e  UHLW        1      845  1500      vr0  1198
192.168.0.242      00:14:2a:08:8f:56  UHLW        1      331  1500      vr0    797
192.168.0.243      00:16:76:c5:58:61  UHLW        1    4768  1500      vr0  1101
192.168.0.244      00:14:2a:8b:79:df  UHLW        1    1715  1500      vr0  1156
192.168.254        192.168.0.1        UGS        0        0  1500    tun0
220.XXX.XXX.240/29  link#2            UC          0        0  1500      vr1
220.XXX.XXX.241      XX:XX:XX:XX:XX:1f  UHLW        2    3755  1500      vr1  1174

I've obviously changed the external IP addresses, but the important information is still there.

BTW, aside from not being able to ping anything on network B from pfSense A, everything else is working fine in terms of cross-network access to internal servers and VoIP systems. Consequently, although I'm academically interested to know what the issue is, please don't bust a gut on this.

Thanks again.

Google translation:

I have my lan at home and want to join the lan of the company, and will then be in the domain of this and use the resources of the company through this magnificent firewall that is Pfsense

(The Spanish forum may be more appropriate if you don't read/write English - El foro español puede ser más apropiado si no sabe leer ni escribir Inglés)

So, you want to connect, using a VPN, to your company?  You'll need to:

a) Have your company set up an OpenVPN server on their network
b) Give you the certificates (and configuration)
c) Configure your pfSense host accordingly

no
1.2 is frozen since a long time.

Problem solved

Have make the interconnection of networks through the use of shared key as its aid for site-to-site, I thought that if used certificates, that was the problem, not Tuesday ping between networks A and B.

Thanks to all

After following the instructions in the VPN Capability OpenVPN doc to open a VPN Client Bridge, are there any special settings in the Firewall Rules that need to be made? My problem is when the OpenVPN Tunnel is enabled after configuring it with the bridge settings I no longer can send emails. My email program hangs while trying to send and receive email. If I disable the OpenVPN Tunnel I can send email.

Other than than when the OpenVPN tunnel is enabled offsite roadwarriors can connect without issue.

For anyone who gets the "ifconfig: BRDGADD tap0: No such file or directory" error check your server bridge entry in the OpenVPN custom options field. The tap0 gave me errors until I realized that the LAN setting for the server bridge was wrong and corrected it and rebooted the machine. The other strange thing is the "<shellcmd>ifconfig bridge0 addm tap0</shellcmd>" entry in the config.xml file seems to not stay at the bottom of the three entries that get entered. After entering them it moved up the next time I looked at the file so it was the first of the three entries for this bridging setup.

Like I said though, the script works perfectly if I run it manually, the only time it doesn't work is when it is invoked as part of the oVPN process itself.

@GruensFroeschli:

The problem is that the traffic seen from the Firewall is not entering the LAN interface in point 3.
The Firewall filters against the outside.
Not against the inside.

I guess you mean that the filters are applied with out instead of in from the gui.
And surely there is a good reason, so will browse the filtering section.
I'm just curious, because i'm used to put the major part of custom rules with in policies.

@GruensFroeschli:

I'm sorry yes you are right.
I dont know what i was thinking when i suggested that ^^"
This only prevents access from the LAN to the clients.

I think what you are trying to do is not possible right now.
Filtering OpenVPN is on the wishlist.

Not pushing a route to the client for the rest of the network is so far your only "protection".
But hey… how many users are out there that know how to add a route ;)

Good news that this is already in the whishlist. I'm new to OpenVPN, but very happy at the momment ("remote" is a good friend).

The route solution is acceptable for some (dumb) users, and it's usefull in a really temporal way.
Maybe to stay a long time, would be possible to add some pf rules from an script (gui independent), anyway have been doing setups in text mode for a long time before pfSense (and by the way i really miss rdr).

GruensFroeschli, thanks for your time and help.

w0w!

i will try it. If it works will write hundred times RTFM.
Will see if this affect the ip assignation.

Thanks.

Josep M.

OpenVPN bridge works like a charm for me.  As mentioned, I am not using CARP on my setup.

please use the search function:

solution: –> http://forum.pfsense.org/index.php/topic,5282.0.html

I'll go with the large neon letters, flames and strobe lights….

You will not get OpenVPN reliably working if the local and remote subnets are the same (or overlap)

See the OpenVPN HowTo: http://openvpn.net/howto.html#numbering.  You will have to renumber one network or stop trying to use OpenVPN.