I'm having the same problem I can make a remote desktop connection from my mobile client to one of my servers and request the webpage of one of the printers in the Office.
I can't directly access that webpage from the mobile client.

As far as I can see, all the gateways are correct.

Firewall rules:
IPSec: Allow all on all for all
WAN: Allow TCP/UDP on port 1194 for all
LAN: Allow All from LAN Net to all

Maby I'm missing something?

//Edit:
When I traceroute a host in the office network from the mobile client, I get a response from the PFSense server and than from the default gateway of PFSense. So PFSense is routing the traffic the wrong way…

Doing the same traceroute from one of my servers, i get the PFSense host, than the router at the office and than the host I'm looking for.

Looks like this is addressed now in the latest version of OpenVPN.  Does anyone know when we might see this change in pfSense?  Or what steps are required to manually upgrade OpenVPN meanwhile?

Here's an excerpt from a recent OpenVPN changelog:

2009.05.30 – Version 2.1_rc17

Increased TLS_CHANNEL_BUF_SIZE to 2048 from 1024 (this will allow for
more option content to be pushed from server to client).

Have you added a route to the VPN on your local LAN's router? You will need that to enable packet routing between your local and remote computers. Simple home routers enable configuration of a few static routes (some are even capable of running RIP). You will need to add a static route to your VPN subnet in your router's configuration. If, for instance, the address of the VPN's virtual interface on your server is 10.8.0.1, your VPN's subnet will most likely be 10.8.0.0/24. I'll use these addresses in my example below. In my Linksys home router to add a route I go to Setup tab, then choose Advanced Routing (it can vary depending on router's manufacturer), and there I type in the following:

Enter Route Name: VPN (or any other name you want)
Destination lan IP: 10.8.0.0
Subnet mask: 255.255.255.0
Default gateway: 192.168.1.254 (<=== this is the VPN server's IP on the LAN)

Obviously adjust IP addressing to your particular setup. That should do the trick.

Good luck

http://szymi.bogsite.org

Hi ! And sorry for my english

I have just set up a vpn with 3 sites
To done that i add satic routes.
The gateway to use with route is the ip assign in the adress pool you have configure your tunnel.

For exemple :

network :

site1 : 192.168.1.0/24
site2 : 192.168.2.0/24
site3 : 192.168.3.0/24

Adress pool :

site1 -> site2 : 10.0.1.0/30
site1 -> site3 : 10.0.2.0/30

When the tunnel is up, and if you do an ifconfig on site1 you will see a interface name (tun or tap).
And in my exemple site1 will have ip 10.0.1.1/30 and at the over side of the tunnel site2 have the ip 10.0.1.2/30

In the second  pool you will have :
site1 10.0.2.1/30 and site3 10.0.2.2/30

So the route to add are :

On site2 (to join site3 by site1)

192.168.3.0 255.255.255.0 10.0.1.1

On site3

192.168.2.0 255.255.255..0 10.0.2.1

Note you have to push this two routes on both side in one time, the sites have to know how to respond to the over site.

Hops it helps you.

(And sorry again for my english)

Just replying with what fixed it. It was as simple as adding "local 2ndexternalipaddress" as a custom option.

Do you mean that you want to do this?
OpenVPN can do this.
There are the stickies explaining how to get this going.

Well I figured out the problem, but I can't come up with a way to fix it (for me) yet. Let's say your client network (the client to the CARPed firewalls) is 10.20.30.0/24. The server network is 10.40.50.0/24, firewall A is 10.40.50.1 and firewall B is 10.40.50.2.

If the client tries to connect to 10.40.50.1 it works fine of course. If the client tries to connect to 10.40.50.2 it goes out on the LAN from 10.40.50.1 correctly, the problem here is actually the reply from 10.40.50.2, because it has no route to 10.20.30.0/24. You can solve this by adding a static route on firewall B (10.40.50.2) on the LAN for 10.20.30.0/24 with the gateway set to 10.40.50.1. This only works if firewall A is the VPN server and firewall B is not (if firewall A is down, there is no VPN connection).

In my situation, I have the OpenVPN server configuration duplicated on both firewalls, and I have it listening on the CARP WAN IP. The client connects to the CARP IP so that if one firewall goes down, it will reconnect to the other one automatically as soon it picks up the CARP IP. That part of it works fine, but I can never connect to the server I'm not connected to.

I can't add a static route because both have routes for 10.20.30.0 already even if the tunnel is not up and as far as I can tell there's no way I can change this behavior, or otherwise allow for automatically changing the route.

@jtpagaran:

Last question: If a need to create additional client..do i really need to create it on the same machine that i build the keys? Can i just copy the "keys" folder to a ney box and redo the instruction in making client files? will it work ? Anyone?

Yes you can as long as you copy everything to the new machine and set the key creation environment exactly as it was on the old machine.

Hi,

Did you solve your problem? I have the same exact error.
Thank you!

Sigh, you are right, my fault: a wrong subnet mask did not allow new routes.

Thank you!

Ok, it's working for us now.  We simply used udp port 1194 for the site-to-site tunnel, and 1193 for the road warrior clients.  Now we're looking into pushing routes into the tunnels.  Anyways, I hope this helps anyone else who's having this problem.

This is solved. I managed to have the remote clients go thru the office gateway and the Win XP machine had as default gateway the old gateway in the office.

@GruensFroeschli:

Set the correct mode.
You're in PSK mode, but the fields you are talking about are only used in PKI mode.

Cheers Champ, that did the trick.

Can't believe it was so simple.

anyone?
btw. no matter what i enter/push, tracert command to LAN always ends at 10.0.8.1 at client …

my pfConfig:

mangeshgg: did you solve it? maybe with the help of my poster before?

If you are using the same subnet on both ends you results would be totally unpredictable.  Make sure that each remote network has their IP network.  That will correct your network connectivity issue.

Now if you are determined to use the same network on each end you would have to break that original subnet into pieces.  
Example:  4 subnets(4 networks of 64 addresses)
             That would be a subnet mask of 255.255.255.240(28 bit mask).

I have 7 VPN tunnels running from behind my PF-Sense each has there on unique 255.255.255.0(24 bit mask).  I even have IPsec VPN tunnels for remote VPN connectivity and OpenVPN connectivity.  Each one of those has their on unique subnet.

So in all my small home/business network has 7 active vpn tunnels, 5 internal subnets(business network, storage network(ISCSI), wireless subnet, IPsec VPN tunnels, OpenVPN tunnels)   I am actively using 5 class C (24 bit subnets) and accessing 7 class networks (24 bit networks)

I work very hard to implement as much technology in my home/business network that keeps my network and infrastructure skill strong.  I have gone totally virtual as well no real servers in my farm.  I am using XenServer Enterprise, with OpenFiler (ISCSI target service enable, SMB service enable, and NFS).  So that in a nut shell is what I am doing with my home network.

RC
.

I fixed the problem using the DNS forwarder and make their A record lookup for the mailserver they use to go to our A record.

Not very fail proof but for now it is working.

Bern,

Thanks so much for that post. After trying some of those steps, like trying to reach the remote subnet from the router, I was able to figure out the problem.

The remote machine with the DNS server has two NICs on different networks. The primary NIC, with the default gateway, is not the network that resolves back to the router. I was already aware of this from previous VPN setups, so I already had a persistent static route for my local subnet here back to pfSense router. This is what made me think it couldn't have been this kind of problem, because clients on this end could contact that machine without a problem.

It wasn't until after I tried to use the local router to connect to that machine that I realized that it couldn't, but it could connect to other machines on the remote end (which used the correct gateway by default). What I needed to do was add a persistent static route on that machine that routed the "internal" subnet of the VPN (172.whatever) back to the gateway, and all is well now.

Most users wouldn't run into this but hopefully this helps someone.

Thanks again!