The only way you get the same address is if:

1. The tunnel network isn't big enough (but I thought openvpn logged that as an error)
2. You're trying (incorrectly) to use the same client certificate on more than one client at the same time, and you don't have the box checked to allow duplicate connections (which is a bad idea).

When configured correctly, according to the wiki doc, that config works fine.

Thanks!

@cmb:

It's not available yet. That issue doesn't pose an imminent threat, we're working on testing the update.

as far as i know you don't need to change any NAT rules …. perhaps you should check your firewall rules.

could some screenshots of openvpn/firewall/nat/routing table ?

also find out whats in the routing table of the roadwarrior

I have managed to fix it by passing "dev tap1" instead of "dev tap" in the advanced configs.
(stupid misstake)

Now my interface connected to tap1 gets the ip from the vpn provider but it doesn't pass it through to my gateway so I can't connect to the internet.
My gateway has the ip-address set to "dynamic" and the interface is set to the one getting the address from tap1. But all it says is "gathering data".

Edit:
Problem solved. I simply changed back to default gateway and then back to the vpn gateway and it worked.
Oh boy, I have learnt a lot today about what could be wrong with this, hopefully I can have it working a while now :)

Thanks for a great software PFSENSE team!

no clue … i've added tons of vlans while maintaining an openvpn connection without such issues

Thanks for the help!

It has been resolved now, I needed to add outbound nat for 10.12.0.0 and 10.13.0.0 on the master, works like a charm now.  Luckily these easy fixes barely cost any time off commercial support.

There are three possibilities for an OpenVPN client to connect to your OpenVPN server:

Just an username and password combination (User Auth)

Just a OpenVPN client certificate

A combination of client certificate and username/password

So if you just have a client certificate and someone else got this certificate he is able to connect to your VPN. If you know that someone lost his certificate or someone has stolen a certificate you can put this certificate on a so called "Certificate Revocation List" which means that connections with this cert will be blocked.

So best thing would be that you think about a username/password and certificate combination.

A more secure possibility would be a certificate + username and one-time-password combination. This can be done in less steps with the freeradius2 package in combination with your OpenVPN Server.
http://doc.pfsense.org/index.php/FreeRADIUS_2.x_package#Enable_Mobile-One-Time-Password_.28OTP.29_support

Hi

Thanks. At the end it was problem on default GW that was set to different IP on clients.
Regards,
Miha

Hi,

finally I solve my problem with site-to-site openVPN Buffalo-pfSense
it was just:) routing problem!!!

1. on pfSense under openVPN Server-Advanced configuration
I have to put
route 192.168.79.0 255.255.255.0; (Buffalo LAN)
route 192.168.76.0 255.255.255.0; (pfSense LAN)
push "route 192.168.76.0 255.255.255.0";(pfSense LAN)
push "route 192.168.79.0 255.255.255.0";(Buffalo LAN)

and pfSense under Client Specific Override-
ifconfig-push 172.30.96.5 172.30.96.6; (openVPN-Network)
push "route 192.168.76.0 255.255.255.0"; (pfSense LAN)
push "route 192.168.79.0 255.255.255.0";(Buffalo LAN)
iroute 192.168.79.0 255.255.255.0 (Buffalo LAN)

2. on Buffalo site

Additional Config
push "route 192.168.79.0 255.255.255.0" (Buffalo LAN)
push "route 192.168.76.0 255.255.255.0" (pfSense LAN)

now I have all my routes and it works!!

http://www.secure-computing.net/wiki/index.php/OpenVPN/Routing
was very helpful!

frosch

My Bad, my bad, my bad, i'm sorry, i'm sorry, problem solved, human error, what happend was that the it person in the location add another pc with the same static ip address of Pfsense box., whenever this guy turned on that pc my Pfsense losted connectivity, sorry if made anybody waste his time.

I've tried it and it appears to work, but there is atleast one "issue"
When adding interfaces to the Ospf, you can set a password. Between OpenOspf servers this works flawlessly in my setup.

If i specify a password on the interface between a quagga host & openOspf, then no neighbours are found. Without password it works without any issues.

I guess this is not this much of a problem in my case, as i use it for routing over openvpn lines that should be pretty secure on its own.
When routing public ip networks it might pose a risk that anyone can join ?

@johnpoz:

"over TCP Port 443 is slow as hell"

Curious about what you consider slow as hell, I run my openvpn over tcp 443 for pretty much same type of reason.  This is normally open no matter where you at.  And can even bounce the openvpn connection off the proxy here.

I am not having any performance issues that I can tell, I can do everything I need to do over the vpn and performance seems fine.  What are you doing exactly that the performance is not up to your expectations?

May have been my upload speed, I will try it again on 443.

Thanks Jimp, may try that out!

Bump - I've had the same thoughts and have basically the same setup.  Is there a way to have the same subnet on either side of an oVPN link and have clients transparently use the DR server if the on-site server were to fail?  How have other people solved this issue.

The exact error message would be more useful.

Sometimes it says there's a TLS error when in fact it's just failing to negotiate because the traffic is blocked by firewall rules…

There is no way (yet)
http://redmine.pfsense.org/issues/34