@marvosa
Its not actually just a modem its a modem+router device. Im very new to networking and stuff, I have no idea if the bridge mode would work with the modem+router.

I did your #2 suggestion and it worked. Only problem now is how I can port forward to other machines/ips not connected directly to the modem+router.

try bringing up a shell and executing the line that is failing

/sbin/ifconfig tun 10.10.0.110 10.10.0.109 mtu 1500 netmask 255.255.255.255 up
ya might get a better error message.

i see this when the vpn becomes disconnected and your user/group is depreciated and can't be removed.
when it re-tries it hasn't dropped permissions yet. But that's a second pass and it is still there so it fails.

see if the tun is there with ifconfig.

@heper:

that could/should work.

the rule at the bottom of the list, will only be triggered when you are trying to send stuff that IS NOT tcp/udp (pings and stuff). If tthat is what you intended, then all is well i guess.

How would I do this so all traffic is sent through the VPN then?
Thanks for your help btw.

NATRules.JPG
NATRules.JPG_thumb

Any one have any ideas? I really need to set the vpn only to some clients.

Thank you

I believe I'm also having this issue.  I was seeing the same Interrupt messages until I put in the latency fix mentioned earlier.  Now I see the below in the logs.  What I don't understand is why are both of my OpenVPN Client Gateways showing an IP address (that they should get from the OpenVPN server), and yet, both gateways show as down under STATUS>OpenVPN?  I'm running 2.1.4 i386.  Thanks!

Aug 3 18:27:36 openvpn[94132]: UDPv4 link remote: [AF_INET]OpenVPN_Server:1194 Aug 3 18:27:36 openvpn[94132]: UDPv4 link local (bound): [AF_INET]WAN_IP Aug 3 18:27:36 openvpn[94132]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 3 18:27:36 openvpn[94132]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Aug 3 18:27:34 openvpn[67441]: UDPv4 link remote: [AF_INET]OpenVPN_Server:1194 Aug 3 18:27:34 openvpn[67441]: UDPv4 link local (bound): [AF_INET]WAN_IP Aug 3 18:27:34 openvpn[67441]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 3 18:27:34 openvpn[67441]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Aug 3 18:27:34 openvpn[94132]: SIGUSR1[soft,ping-restart] received, process restarting Aug 3 18:27:34 openvpn[94132]: [UNDEF] Inactivity timeout (--ping-restart), restarting Aug 3 18:27:32 openvpn[67441]: SIGUSR1[soft,ping-restart] received, process restarting Aug 3 18:27:32 openvpn[67441]: [UNDEF] Inactivity timeout (--ping-restart), restarting

Finally fixed  :)

It wasn't pfSense but VMware vSwitch that caused the problem, allowing the vSwitch to accept "Promiscuous Mode" fixed it (thanks to this post: http://serverfault.com/questions/549336/pfsense-2-1-openvpn-cant-reach-servers-on-the-lan)

Also when I do a tracert from site A (89.*) this is the result:

C:\Users\nca45>tracert 192.168.90.1

Tracing route to VS1 [192.168.90.1]
over a maximum of 30 hops:

1    <1 ms    <1 ms    <1 ms  192.168.89.254
  2  200 ms    28 ms    29 ms  10.0.8.1
  3    20 ms    37 ms    38 ms  VS1 [192.168.90.1]

Trace complete.

C:\Users\nca45>tracert 192.168.90.3

Tracing route to 192.168.90.3 over a maximum of 30 hops

1    <1 ms    <1 ms    <1 ms  192.168.89.254
  2    <1 ms    <1 ms    <1 ms  xxx.optonline.net [108.170.xx.xx
]
  3    *        *        *    Request timed out.
  4  ^C
C:\Users\nca45>tracert 192.168.90.10

Tracing route to DATA [192.168.90.10]
over a maximum of 30 hops:

1    <1 ms    <1 ms    <1 ms  192.168.89.254
  2    22 ms    38 ms    43 ms  10.0.8.1
  3    21 ms    20 ms    23 ms  DATA [192.168.90.10]

Trace complete.

I can ping my physical nodes perfectly. (1 and 10)  I ping my virtual node (3) and I get nothing.

Any ideas?

The route-nopull option did the trick !

Many thanks !

Well the Client side looks essentially correct, but without seeing the server side, it's hard to tell.

One further note, it wasn't clear which LAN's belong to the client and which to the server -

Client LAN (pfSense side) - 192.168.0.0/24 ?
Server LAN (FLI4L side)    - 192.168.100.0/24 ?

The main firewall rule for pfsense is to allow all under the OpenVPN interface.

I have never seen the FLI4L configurations for OpenVPN (or anything else) but the things to look for would be the network routed over the tunnel.  You might want to check the routing tables on bith the pfSense and the FLI4L side after the tunnel is established.  The other place to look is the logs under OpenVPN. Again I don't know what FLI4L provides, but adding a "verb 5" or even a "verb 7" to the "Advanced Configuration" section of the OpenVPN config(s) should log tons of info about the established tunnel (turn it off after you get the tunnel working).

Just as an aside, why are you using FLI4L on the server side?  From my (very) cursory look at FLI4L it seems to be a lightweight equivalent to pfSense.  Any reason not to instal pfSense on the server side? (not requiring, just asking)

Hi MnM,

Should be possible if pfSense supports the OpenVPN configuration. You will use rules to decide which VPN tunnel that the traffic will be routed out (routing-based policy). And combined with schedules, you can create several rules, where one rule is active at a specified time and the others inactive. The caveat is that all the tunnels must have a different gateway address (which it probably has, since it's different parts of the world).

Your screen shot doesn't show the upper portion of the OpenVPN page, what mode is the OpenVPN server using (should be in the top line of the OpenVPN server config screen)? Can you post the upper two sections of the OpenVPN server config "General Information" and "Cryptographic Settings"?

What's interesting is that I don't see any lines in your screenshot for the Local and/or Remote IPv4 networks in the config.  Which would make it difficult for the connection to route any traffic.

Did you use the OpenVPN wizard to create the OpenVPN server?

You might try to turn off NAT reflection on the OpenVPN port forward rule.
That should stop internal connections from reaching the external port.

Normally I'm fighting this case in the reverse sense (trying to make external rules work for internal traffic)  ;)

OK I got it. Had to setup a simple vpn traffic rule and allow pap authentication on the radius server.