I figured out the answer to my problem. I needed to add a route to the gateway at B for the subnet IP's being assigned the the vpn users

The OpenVPN Forum thread is: Involvement of FOX-IT in OpenVPN https://forums.openvpn.net/topic10180.html I saw it in a Wilders Security Forum thread: Involvement of FOX-IT in OpenVPN https://www.wilderssecurity.com/showthread.php?p=2196713 The Wikipedia page on FOX-IT: http://en.wikipedia.org/wiki/Fox-IT Edit: The AirVPN forum admin just said this: Basically the statements by Sommerseth hold and Yonan's analysis, as well as the OpenVPN community work and the peer-review of OpenVPN after 4 months from that thread, show that there's no such vulnerability neither on OpenVPN 2.2.x nor on OpenVPN 2.3.0. Additionally, Palatinux team members have proved unable to support their claims, even after a clear invitation to do so by Bakker from PolarSSL (see his message on the very same thread). Unless Palatinux provides evidence of their claims (and in 4 months they failed to do so), all the stuff is just an attempt to inject FUD (Fear, Uncertainty and Doubt) for purposes we are not willing to comment. https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=8070&Itemid=142

It might be bad form to answer your own question but I wanted ensure that this thread has closure. I found the solution. I had to manually create an interface for VPN (OPT1) and bridge it to the LAN interface. I had assumed that the wizard & settings would have done this automagically like it is on other firmwares.

This worked like a charm, Thanks!  It makes a lot more sense now. Have a good one.

While connecting through ubuntu client system following error occured NOTE: unable to redirect default gateway – Cannot read current default gateway from system Is it causing the issue.Can any one help me.........

On OpenVPN Server you set the tunnel network. for example 10.10.10.0/24 10.10.10.0/30 is the OpenVPN Server itself 10.10.10.4/30 is the first OpenVPN client which connects 10.10.10.8/30 is the second OpenVPN client which connects …. 10.10.10.252/30 is the 63rd OpenVPN client which connects. In short: Every client connection on OpenVPN needs a subnet of /30 First IP: Network IP Second IP: OpenVPN Server IP Third IP: OpenVPN Client IP Foruth IP: Broadcast IP This is how every client connection/subnet looks like.

I restored from a previous backup that didn't contain any configuration information for OpenVPN. Ping now works. And doesn't stop working after 30 seconds of being up. So far so good. I imported the pfsense certificate authority certificate and key (ca.crt & ca.key) into the Cert Manager CA Authority tab from our older Linux-based router which used easyrsa to generate those certificates/keys. Then I went to the client certificate tab and imported Firewall.crt & Firewall.key from our Linux-based router to a 'Firewall' certificate entry. I also imported a client certificate and key into a new client certificate entry called DougSampson. I went to the OpenVPN configuration and imported the contents of the ta.key into the TLS-Authentication box. For the Peer Certificate Authority I chose the Firewall Certificate Authority certificate (ca.crt in this case) and for the Peer Certificate Revocation List I chose the Firewall Certificate Authority entry (we didn't employ a CRL list on our Linux-based router). For the Server Certificate, I chose the Firewall server certificate (in this case, the Firewall.crt) for the Server Certificate box. I chose 1024 bits for the DH Parameter Length. We had a dh1024.pem file from our Linux-based router but didn't know where to put it- there's no box for selecting the dh1024.pem file. It currently sits in the /root/easyrsa4pfsense/keys folder. POSTSCRIPT: I now notice 'dh /etc/dh-parameters.1024' in server1.conf. Should I replace the contents of that file with the contents from the /root/easyrsa4pfsense/keys/dh1024.pem? The contents of server1.conf is as follows: dev ovpns1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher BF-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 69.xxx.xxx.xxx tls-server server 10.0.8.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc tls-verify /var/etc/openvpn/server1.tls-verify.php lport 1194 management /var/etc/openvpn/server1.sock unix max-clients 5 push "route 192.168.101.0 255.255.255.0" push "dhcp-option DOMAIN dawnsign.com" push "dhcp-option DNS 192.168.101.1" push "dhcp-option DNS 192.168.101.4" push "dhcp-option DNS 192.168.101.7" push "dhcp-option DNS 192.168.101.254" push "dhcp-option NTP 192.168.101.254" push "dhcp-option NTP 192.168.101.4" push "dhcp-option WINS 192.168.101.4" client-to-client ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024 crl-verify /var/etc/openvpn/server1.crl-verify tls-auth /var/etc/openvpn/server1.tls-auth 0 comp-lzo passtos persist-remote-ip float push "route 192.168.102.0 255.255.255.0" Content of client.ovpn: client dev tun proto udp remote 69.xxx.xxx.xxx 1194 resolve-retry infinite nobind persist-key persist-tun ca ca.crt cert DougSampson.crt key DougSampson.key tls-auth ta.key 1 comp-lzo verb 3 The client config file worked just fine with our existing Linux-based router running OpenVPN. Now when I try to connect, it fails with a TLS handshake error. Here is what the openvpn.log spits out: Feb 28 10:07:05 pfsense openvpn[11729]: event_wait : Interrupted system call (code=4) Feb 28 10:07:05 pfsense openvpn[11729]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1542 10.0.8.1 10.0.8.2 init Feb 28 10:07:05 pfsense openvpn[11729]: SIGTERM[hard,] received, process exiting Feb 28 10:07:05 pfsense openvpn[48656]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug  6 2012 Feb 28 10:07:05 pfsense openvpn[48656]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 28 10:07:05 pfsense openvpn[48656]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file Feb 28 10:07:05 pfsense openvpn[48656]: TUN/TAP device /dev/tun1 opened Feb 28 10:07:05 pfsense openvpn[48656]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Feb 28 10:07:05 pfsense openvpn[48656]: /sbin/ifconfig ovpns1 10.0.8.1 10.0.8.2 mtu 1500 netmask 255.255.255.255 up Feb 28 10:07:05 pfsense openvpn[48656]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1542 10.0.8.1 10.0.8.2 init Feb 28 10:07:05 pfsense openvpn[50174]: UDPv4 link local (bound): [AF_INET]69.xxx.xxx.xxx:1194 Feb 28 10:07:05 pfsense openvpn[50174]: UDPv4 link remote: [undef] Feb 28 10:07:05 pfsense openvpn[50174]: Initialization Sequence Completed Feb 28 10:08:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 Re-using SSL/TLS context Feb 28 10:08:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 LZO compression initialized Feb 28 10:09:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Feb 28 10:09:06 pfsense openvpn[50174]: <ovpn client="" ip="" addr="">:51681 TLS Error: TLS handshake failed</ovpn></ovpn></ovpn></ovpn> Moreover, the pfsense server stops being able to ping! After rebooting, I'm unable to ping at all. It looks like there is a misconfiguration error somewhere in there and I cannot figure it out. Can anyone spot any errors? I notice that in the server1.conf file, the cipher is specified but it is not specified in the client config file. Is this an error? Are there any other errors? ~Doug

My example of this "feature" is at http://forum.pfsense.org/index.php/topic,59464.0.html I have noticed it with both Peer-to-peer shared key and SSL/TLS links every now and then. I saw it just now and managed to gather some data.

figured it out by myself, NAT rules doesn't seem to be created by default, so i added the outbound NAT rules myself …  8)

For info heres my .ovpn config file persist-tun persist-key cipher BF-CBC tls-client client remote 88.77.66.55 443 tcp http-proxy 10.11.13.30 80 auth-user-pass Here's the iOS openvpn log: 2013-02-27 12:40:26 –--- OpenVPN Start ----- 2013-02-27 12:40:26 EVENT: RESOLVE 2013-02-27 12:40:26 EVENT: WAIT 2013-02-27 12:40:27 Transport Error: TCP connect error on '88.77.66.55' for TCP session: Connection refused 2013-02-27 12:40:27 Client terminated, restarting in 2...

haha… I cannot believe this. I feel like a right noob now  ;D Thanks a lot! it works in a real browser.

@phil.davis: NAT the incoming OpenVPN road warrior links/clients onto your LAN That's one of the solutions I have looked for but couldn't find how to do so. Another point is I wouldn't know which client connected because of the NAT but that would be acceptable if I would get it working

Thanks, but where did you put the command? Do you mean in the box "Additional configuration options" in the export client tab? Or should i download the files and edit the config?

If you use user auth on the server side, and you don't save the password on the client side, yes. If you are only doing certificate auth, probably not.

pfSense version? OS client version? OpenVPN client version? Do you have a LAN rule permitting all traffic to the whole tunneling network (policy routing)? Are you sure that clients aren't using your subnets for their local network? Have the affected clients more than a NIC? Are allways the same clients? Do you see any message at OpenVPN logs (server & affected clients)? Are you using tun or tap? Are you using tcp or udp? Do you see anything at your pfSense firewall log?

So the issue is this ##@(# DSL modem. Because in pfSense 1.2.3 only "WAN" interface could be PPPoE, the modem was configured for PPPoE. But in this mode the DSL modem assigns the IP as a /8 to pfSense! So since both IP address (everything is dynamic) happen to start with 198. there was a conflict. After configuring the PPPoE on pfSense the subnet mask is 255.255.255.255 and there's no more conflict. :'(

Finally it works! I had two errors: Incorrect manual NAT Outbound Incorrect policy routing at LAN, as you said. $ pfctl -s rules | grep VPNs pass in quick on em0 inet from <adm_pcs> to 192.168.XXX.0/22 flags S/SA keep state label "USER_RULE: Access from LAN to VPNs"</adm_pcs> em0 is my LAN adm_pcs is my alias for administrator's computers at the LAN side. 192.168.XXX.0/22 covers all my OpenVPN networks (I have many OpenVPN servers running). Version 2.0.1-RELEASE (i386) built on Mon Dec 12 19:00:03 EST 2011 FreeBSD 8.1-RELEASE-p6 Many thanks!

remote are incorrectly set to the same HQ subnet (192.168.1.x) I would be more convenient to change the remote, I try,.. thanks!