An access point does require a default gateway if you're managing it from off-subnet.

you just need a port forward on the OpenVPN interface. Probably easier if you have proper routing on your VPS to the internal host on your network so it can just route it in, no need for additional NAT in between.

I dont think this is the problem either.  I had a rule under firewall rules - LAN allowing / to */1194.  All of my outbound traffic rules are defined similar to this on the lan tab (and the other traffic always originates from other local machines).  However, since this OpenVPN server actually sits on the same box as the WAN interface, I thought perhaps it was being dropped.  I tried adding a similar rule under WAN tab and the problem persists.

I have logging of packets dropped by default turned on (I assume this checkbox applies to all interfaces) and the logs do not show anything being dropped on 1194.

To verify its not a firewall issue, I disabled openvpn server and spun up netcat on udp/1194.  Connected to it from external network and could send text both ways no problem.

Tried using TCP too with similar results.  We can see the tcp connection established but immediately reset before trying to auth.

Sun Feb 19 14:01:09 2012 WARNING: Make sure you understand the semantics of –tls-remote before using it (see the man page).
Sun Feb 19 14:01:09 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun Feb 19 14:01:09 2012 Re-using SSL/TLS context
Sun Feb 19 14:01:09 2012 LZO compression initialized
Sun Feb 19 14:01:09 2012 Attempting to establish TCP connection with WAN-IP:1194 [nonblock]
Sun Feb 19 14:01:10 2012 TCP connection established with WAN-IP:1194
Sun Feb 19 14:01:10 2012 TCPv4_CLIENT link local: [undef]
Sun Feb 19 14:01:10 2012 TCPv4_CLIENT link remote: WAN-IP:1194
Sun Feb 19 14:01:10 2012 Connection reset, restarting [0]
Sun Feb 19 14:01:10 2012 SIGUSR1[soft,connection-reset] received, process restarting

Solved!

Set rule generation to Manual in Firewall > NAT > Outbound Create rule (Interface: MYVPN, Protocol: any, Source: Network 10.0.0.0/24, Destination: Network 10.8.0.1/32)

When I type 10.8.0.1 in my laptop's browser, I now see a webpage running on my home server, which was my goal. Thanks for the replies!

In order for broadcasts to traverse the VPN, it will need to be set up as a bridge.

I don't know if this will be of any help to you, I was having the exact same issues when trying to connect to pfsense from a windows openvpn client, I fixed it by changing from tap to tun and changing interface to any. I made the last change so I could test the tunnel from inside the network, it all worked fine, then I switched to my mobile broadband connection and it all worked!

I also used the OpenVPN client export utility (you can install from packages) to export the configuration.

Good luck.

@pfnewbie12:

Hi, new to pf looking for some guidance, I have the following set up,

office1 - 10.0.1/24
office2 - 10.20.1/24
office1 and office2 site to site is working using 10.0.9/30, i can traverse both ways

i have just setup a road warrior vpn into office2 using 10.0.8/30 and i can access 10.20.1/24 fine.  what do i need to do to access office1 10.0.1/24 when i am on the vpn?  i have checked the firewall logs and allowed the blocked access but it looks like i'm missing a route configuration somewhere?

just add on the OpenVPN server on office the following command in the advanced options:

push "route 10.0.1.0 255.255.255.0";

Then the OpenVPN server send a static route to the OpenVPN Client (RoadWarrior).
But you have to allow the traffic from the OpenVPN RoadWarrior Tunnel network on office2 and office1 - but I am sure you know that.

Your OpenVPN firewall rules are only allowing traffic on port 1194.  Remove that rule under OpenVPN, it's not doing anything productive (unless of course you are trying to establish a tunnel through the tunnel to somewhere inside the local network, then it would be doing something).
Add a rule under OpenVPN with *'s across the board, this will allow all traffic through the tunnel.  Then you can tighten down from there if that is something you require.  Get it working first, then lock it down is usually my philosophy.

I added keepalive 120 240 but still no luck :-( If the connection goes down and a reconnect is done, an error "AUTH_failed" is thrown (Because the old connection still exists on the server of my VPN-Provider) from the Server, it stays down until you manually restart it :-( Is there a way to add (re)connect retries although of the "AUTH_failed" message?

Is there any tutorial to show hwo to setup OPEN vpn with PKI?  I have successfully created a VPN tunnel for a user but I need to have 4 users connected and I don't' want to open 4 ports up.  I would like them all communicating through the same port.

Is there any advantages / disadvantages to setup this way?

I switched to a Firebox X700 and OpenVPN now works…weird...

Not sure really. It's something we'd like to see working (VPN Bonding) but lagg may not be the most efficient way to get that done in the long run. It's just been a topic lately since zeroshell is doing it that way.

Reconfiguring the lagg as needed may not be difficult to add in the backend but it seems like there are quite a few issues with doing it that way that may end up making it not really feasible to use.

Another way we'd mentioned is doing MLPPP over the tunnels to bond them but that could be even more of a challenge.

Good to know. Thanks Chris!  :)

Thank you for your response, I did changes as suggested :

and now, on remote side routing :

Kernel IP routing table Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 10.10.10.1      10.10.10.5      255.255.255.255 UGH   0      0        0 tun11 10.10.10.5      *               255.255.255.255 UH    0      0        0 tun11 10.8.0.2        *               255.255.255.255 UH    0      0        0 tun21 192.168.141.254 *               255.255.255.255 UH    0      0        0 vlan1 192.168.20.0    10.10.10.5      255.255.255.0   UG    0      0        0 tun11 10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun21 192.168.10.0    *               255.255.255.0   U     0      0        0 br0 192.168.141.0   *               255.255.255.0   U     0      0        0 vlan1 127.0.0.0       *               255.0.0.0       U     0      0        0 lo default         192.168.141.254 0.0.0.0         UG    0      0        0 vlan1

On OpenVPN server side :

Routing tables Internet: Destination        Gateway            Flags    Refs      Use  Netif Expire default            178.26.23.254      UGS         0  1071098    vr1 10.10.10.0/24      10.10.10.2         UGS         0        3 ovpns2 10.10.10.1         link#12            UHS         0        0    lo0 10.10.10.2         link#12            UH          0        0 ovpns2 127.0.0.1          link#6             UH          0    14102    lo0 192.168.10.0/24    10.10.10.2         UGS         0       54 ovpns2 192.168.20.0/24    link#10            U           0  1279213 bridge 192.168.20.254     link#10            UHS         0        0    lo0

And now I'm checking from host behind OpenVPN server (192.168.20.1)

[~] # ping 192.168.10.130 PING 192.168.10.130 (192.168.10.130): 56 data bytes ^C --- 192.168.10.130 ping statistics --- 53 packets transmitted, 0 packets received, 100% packet loss [~] # ping 192.168.10.1 PING 192.168.10.1 (192.168.10.1): 56 data bytes ^C --- 192.168.10.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss [~] # ping 10.10.10.6 PING 10.10.10.6 (10.10.10.6): 56 data bytes 64 bytes from 10.10.10.6: icmp_seq=0 ttl=63 time=62.1 ms 64 bytes from 10.10.10.6: icmp_seq=1 ttl=63 time=64.8 ms 64 bytes from 10.10.10.6: icmp_seq=2 ttl=63 time=46.9 ms ^C --- 10.10.10.6 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 46.9/57.9/64.8 ms [~] # ping 10.10.10.1 PING 10.10.10.1 (10.10.10.1): 56 data bytes 64 bytes from 10.10.10.1: icmp_seq=0 ttl=64 time=0.4 ms 64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=0.2 ms ^C --- 10.10.10.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.3/0.4 ms [~] # ping 10.10.10.2 PING 10.10.10.2 (10.10.10.2): 56 data bytes ^C --- 10.10.10.2 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss [~] # ping 10.10.10.5 PING 10.10.10.5 (10.10.10.5): 56 data bytes ^C --- 10.10.10.5 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss [~] # traceroute 192.168.10.130 traceroute to 192.168.10.130 (192.168.10.130), 30 hops max, 40 byte packets 1  192.168.20.254 (192.168.20.254)  1.113 ms  0.377 ms  0.348 ms 2  *^C [~] #

So I can ping 10.10.10.6 which is on tunnel end, but nothing on 192.168.10.0 network.

Log from client :

Feb  9 12:23:34 tomato daemon.notice openvpn[1121]: OpenVPN 2.1.1 mipsel-unknown-linux-gnu [SSL] [LZO2] [EPOLL] built on Dec  4 2011 Feb  9 12:23:34 tomato daemon.warn openvpn[1121]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info. Feb  9 12:23:34 tomato daemon.warn openvpn[1121]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb  9 12:23:34 tomato daemon.notice openvpn[1121]: LZO compression initialized Feb  9 12:23:34 tomato daemon.notice openvpn[1121]: Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ] Feb  9 12:23:34 tomato daemon.notice openvpn[1121]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ] Feb  9 12:23:35 tomato daemon.notice openvpn[1127]: Socket Buffers: R=[32767->65534] S=[32767->65534] Feb  9 12:23:35 tomato daemon.notice openvpn[1127]: UDPv4 link local: [undef] Feb  9 12:23:35 tomato daemon.notice openvpn[1127]: UDPv4 link remote: xx.xx.xx.xx:1195 Feb  9 12:23:35 tomato daemon.notice openvpn[1127]: TLS: Initial packet from xx.xx.xx.xx:1195, sid=76b8ea0b 54d5e74d Feb  9 12:23:35 tomato daemon.notice openvpn[1127]: VERIFY OK: depth=1, xxxxxxxxxxxxxxxxxxxx Feb  9 12:23:35 tomato daemon.notice openvpn[1127]: VERIFY OK: depth=0, xxxxxxxxxxxxxxxxxxxx Feb  9 12:23:37 tomato daemon.notice openvpn[1127]: Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key Feb  9 12:23:37 tomato daemon.notice openvpn[1127]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Feb  9 12:23:37 tomato daemon.notice openvpn[1127]: Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key Feb  9 12:23:37 tomato daemon.notice openvpn[1127]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Feb  9 12:23:37 tomato daemon.notice openvpn[1127]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Feb  9 12:23:37 tomato daemon.notice openvpn[1127]: [ag-net.eu] Peer Connection Initiated with 178.26.16.94:1195 Feb  9 12:23:40 tomato daemon.notice openvpn[1127]: SENT CONTROL [ag-net.eu]: 'PUSH_REQUEST' (status=1) Feb  9 12:23:40 tomato daemon.notice openvpn[1127]: PUSH: Received control message: 'PUSH_REPLY,route 192.168.20.0 255.255.255.0,route 10.10.10.1,topology net30,ping 10,ping-restart 60,ifconfig 10.10.10.6 10.10.10.5' Feb  9 12:23:40 tomato daemon.notice openvpn[1127]: OPTIONS IMPORT: timers and/or timeouts modified Feb  9 12:23:40 tomato daemon.notice openvpn[1127]: OPTIONS IMPORT: --ifconfig/up options modified Feb  9 12:23:40 tomato daemon.notice openvpn[1127]: OPTIONS IMPORT: route options modified Feb  9 12:23:40 tomato daemon.notice openvpn[1127]: TUN/TAP device tun11 opened Feb  9 12:23:40 tomato daemon.notice openvpn[1127]: TUN/TAP TX queue length set to 100 Feb  9 12:23:40 tomato daemon.notice openvpn[1127]: /sbin/ifconfig tun11 10.10.10.6 pointopoint 10.10.10.5 mtu 1500 Feb  9 12:23:40 tomato daemon.notice openvpn[1127]: updown.sh tun11 1500 1558 10.10.10.6 10.10.10.5 init Feb  9 12:23:41 tomato daemon.notice openvpn[1127]: /sbin/route add -net 192.168.20.0 netmask 255.255.255.0 gw 10.10.10.5 Feb  9 12:23:41 tomato daemon.notice openvpn[1127]: /sbin/route add -net 10.10.10.1 netmask 255.255.255.255 gw 10.10.10.5 Feb  9 12:23:41 tomato daemon.notice openvpn[1127]: Initialization Sequence Completed

And another thing, on client router (Tomato) I have syslog pointing to 192.168.20.1 (internal NAS behind pfsense router), what I see in tcpdump :

12:59:40.108160 IP 10.10.10.6.2048 > 192.168.20.1.514: SYSLOG cron.info, length: 97 12:59:40.144467 IP 10.10.10.6.2048 > 192.168.20.1.514: SYSLOG syslog.info, length: 37

And I can see those entries in syslog, but it's coming from 10.10.10.6 not 192.168.10.1

Yes, I get that, you want broadcasts to traverse the VPN, but what's your end game?  What are you trying to set up that you think won't (or doesn't) work with a routed solution?

Good one! I needed this!

Thanks Nachtfalke!

Kostas