Site to site - all traffic through tunnel

[bjorktorp]

I know that this topic has been discussed before, but unfortunately I'm too stupid to understand. I'm new to OpenVPN, but fairly experienced with IPSEC, mostly with Nortel gear but also with pfSense. Now I want to start using OpenVPN in situations where IPSEC is a bit tricky - to establish temporary VPNs behind firewalls where I have no administrative rights.

My problem is to force ALL traffic from the branch office through the tunnel to the central site.

My setup:

pfSenseServer:

• 1.2-RC2 Embedded
• Placed behind the corporate firewall, with UDP port 1194 redirected to pfSenseServer.
• A firewall rule on the WAN interface, allowing OpenVPN traffic.
• I have also added static routes to my internal networks.
• In "address pool" I use 192.168.200.0/24
• "Remote network" 172.18.200.0/24, which is the subnet of the branch office for this test.

pfSenseClient:

• 1.2-RC2 Embedded
• WAN gets it's address through DHCP.
• placed behind "unknown" firewall
• "Interface IP": 192.168.200.0/24, same as "Address pool" on the server. (Maybe not so wise?)
• "Remote network": Various (see below)

There is no problem at all to establish the connection. If I set 172.16.235.0/24 as "Remote network" in pfSenseClient, I can reach all devices on that net from the branch office. If I set 172.0.0.0/8, I reach all relevant internal nets to which I have added routes.
But, when I set 0.0.0.0/0, as I am used to do in IPSEC to get all traffic through the tunnel, there is a No-NO. When I look in the log I see:
openvpn[16135]: ERROR: FreeBSD route add command failed: shell command exited with error status: 1
0.0.0.0/0 is obviously the wrong way to do it. I hope some kind person is willing to lead me in the right direction….

/Roger

[GruensFroeschli]

You need to add some custom options.
You need to push the new DNS your client will be using, and you need to use the command to redirect all traffic.

on server side:
push "dhcp-option DNS x.x.x.x";push "redirect-gateway def1"

and that's about it :)
you need to push a DNS entry that's reachable through the tunnel because after the tunnel is established, DNS requests will be redirected too.

As a side note: You say you added static routes. Dont do that. Use the custom options of OpenVPN. If you enter in the field: "remote network" 10.0.4.0/24 then that does nothing else than add the line:
"route 10.0.4.0 255.255.255.0"
to the config. You can add many more "route" lines in the custom options.
When the tunnel comes up the OpenVPN-process automatically adds these routes to the routing table and if the tunnel goes down removes them.

The push "redirect-gateway def1" from above does something similar on the client: the client process adds automatically a 0.0.0.0/1 and 128.0.0.0/1 route to the routing table of the client.
without using 0.0.0.0/0 you have all traffic redirected but still have your original gateway (so that the encrypted traffic gets to the internet).

For more infos about the redirect, the howto of openVPN:
http://openvpn.net/howto.html#redirect

For more infos about the route, check out the "push" and the "route" part of the MAN-pages (redirect might also be interresting):
http://openvpn.net/man.html

[bjorktorp]

Thanks a lot for fast reply!

@GruensFroeschli:

You need to add some custom options.
You need to push the new DNS your client will be using, and you need to use the command to redirect all traffic.

you need to push a DNS entry that's reachable through the tunnel because after the tunnel is established, DNS requests will be redirected too.

"your client" - I guess you refer to the PC's and other equipment on the branch office LAN. They are not affected by any change of dns-server. Their primary dns server is on their local LAN and the secondary is on our central location, that is within the tunnel allready.

@GruensFroeschli:

As a side note: You say you added static routes. Dont do that. Use the custom options of OpenVPN. If you enter in the field: "remote network" 10.0.4.0/24 then that does nothing else than add the line:
"route 10.0.4.0 255.255.255.0"
to the config. You can add many more "route" lines in the custom options.
When the tunnel comes up the OpenVPN-process automatically adds these routes to the routing table and if the tunnel goes down removes them.

The static routes are for my internal networks - several hundreds. I cannot see how the pfSense OpenVPN server box otherwise would know the address of my backbone router. My theory of operation in this case is to lead all traffic from the branch office into the tunnel, which terminates in the pfSense box. Internal traffic is then forwarded to the backbone router and Internet traffic make a u-turn in the pfSense box, and leave through the corporate firewall.

@GruensFroeschli:

For more infos about the redirect, the howto of openVPN:
http://openvpn.net/howto.html#redirect

For more infos about the route, check out the "push" and the "route" part of the MAN-pages (redirect might also be interresting):
http://openvpn.net/man.html

Thanks for the info. I'll dig into that. Sometimes it takes some extra energy to map that kind of information to the setup in the pfSense GUI.

Alfter all that said, I have tested your suggestion. Still I'm unsure what to put in the "Remote network" box in the pfSenseclient box. I tried leaving it blank, as that was an option too. No success. Perhaps the solution is to make two tunnels. One for 0.0.0.0/1 and one for 128.0.0.0/1. But that's an ugly one…

[GruensFroeschli]

@bjorktorp:

Thanks a lot for fast reply!

@GruensFroeschli:

You need to add some custom options.
You need to push the new DNS your client will be using, and you need to use the command to redirect all traffic.

you need to push a DNS entry that's reachable through the tunnel because after the tunnel is established, DNS requests will be redirected too.

"your client" - I guess you refer to the PC's and other equipment on the branch office LAN. They are not affected by any change of dns-server. Their primary dns server is on their local LAN and the secondary is on our central location, that is within the tunnel allready.

I mean with "your client" your pfSense-box (as openVPN-client) in your branch office.
I assume the rest of your PC's in your branch office get routed through your remote pfSense.
So if the routing table of the pfSense gets changed in a way that everything goes through the tunnel, all your other PC's get redirected through the tunnel.
If your primary DNS-server gets routed through your remote pfSense you will have to setup some kind of policy based routing that this DNS server still has direct access to the internet.
(Setup a firewall rule for the IP of the server and select as gateway not * –>pfSenses routingtable, but the gateway you want the traffic to go out)
After the redirect is in place this Server would be routed through the tunnel too. (or do you want that?)

@GruensFroeschli:

As a side note: You say you added static routes. Dont do that. Use the custom options of OpenVPN. If you enter in the field: "remote network" 10.0.4.0/24 then that does nothing else than add the line:
"route 10.0.4.0 255.255.255.0"
to the config. You can add many more "route" lines in the custom options.
When the tunnel comes up the OpenVPN-process automatically adds these routes to the routing table and if the tunnel goes down removes them.

The static routes are for my internal networks - several hundreds. I cannot see how the pfSense OpenVPN server box otherwise would know the address of my backbone router. My theory of operation in this case is to lead all traffic from the branch office into the tunnel, which terminates in the pfSense box. Internal traffic is then forwarded to the backbone router and Internet traffic make a u-turn in the pfSense box, and leave through the corporate firewall.

I dont really follow you here.
Could you provide a small picture?
What i tried to tell before: if you want to specify what lies on the other end of the tunnel, dont use static routes, since the "route-command" (and iroute) from openVPN adds and removes dynamicly the necessary routes to the table.
Or do you mean that yur remote box wouldnt even know where your main office is without these entries?

If you use openVPN you dont reallly need to add any manual static route since everything (adding and removing static routes) is handled by the openVPN-process.

@GruensFroeschli:

For more infos about the redirect, the howto of openVPN:
http://openvpn.net/howto.html#redirect

For more infos about the route, check out the "push" and the "route" part of the MAN-pages (redirect might also be interresting):
http://openvpn.net/man.html

Thanks for the info. I'll dig into that. Sometimes it takes some extra energy to map that kind of information to the setup in the pfSense GUI.

Alfter all that said, I have tested your suggestion. Still I'm unsure what to put in the "Remote network" box in the pfSenseclient box. I tried leaving it blank, as that was an option too. No success. Perhaps the solution is to make two tunnels. One for 0.0.0.0/1 and one for 128.0.0.0/1. But that's an ugly one…

The remote network box is here to add the routes to the remote network. but since you created static routes thats no longer necessary. This box is why i meant not to use static routes :) If you fill in the infos here you dont need the static route.
If you want to add more that one route through the tunnel you just need to add the commands under "custom options" (since you cann specify only one network in this box).

The 0.0.0.0/1 and 128.0.0.0/1 is not meant to be done manually.
This is just what the openVPN process does behind the scene to redirect all traffic.

I think this link is more about what you want to do: http://openvpn.net/howto.html#scope

[bjorktorp]

I'll post the picture later on. Just some comments on the way…

About the server:
Yes, I want the server, including dns-lookups to go through the tunnel. It has, controlled, Internet-access through the tunnel.

Static routes:
No I don't add the routes to specify the remote nets. I add them on the LAN side of the central pfSense gate to route traffic in the right direction once it exits the tunnel.

The "remote networks" box:
Yes, I know that this is where I should type the nets available on the other side of the tunnel. Since I want all traffic through the tunnel I initially set it to 0.0.0.0/0. But that gave me the openvpn[16135]-error in the log. In my humble opinion, and with all my lack of knowledge, I believe that this is the only problem. If it would be possible to set 0.0.0.0/0 in the "Remote net" box, all would be OK. I have used that setup in IPSEC, both on Nortel and pfSense boxes.

At last: I agree that a picture would help to sort out the confusion. I hope to have it ready tomorrow.

[GruensFroeschli]

Ok i think i understand now.
But the problem with 0.0.0.0/0 as remote network is that the openVPN-process would add this route to the systems routing table and then no longer be able to send the encrypted traffic to the internet since the default route is a tunnel to itself. do you see the problem?

That's why the
push "redirect-gateway def1"
exists. This command does basicly add a 0.0.0.0/0 to the table, but creates first a static route to the previous gateway. The def1 is a bit different since it does not wipe the original gateway but still override it.
Just add this line to the custom options on your server and all traffic on the client-pfSense will be redirected through the tunnel.

Snip from man pages:

–redirect-gateway [local] [def1]
    (Experimental) Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN.

This option performs three steps:

(1) Create a static route for the –remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop.

(2) Delete the default gateway route.

(3) Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).

When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored.

Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omitted.
**Add the def1 flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

Using the def1 flag is highly recommended, and is currently planned to become the default by OpenVPN 2.1.**

[bjorktorp]

I'm sorry for my silence. I have been out on the road a couple of days…

When we now agree on what I am trying to do, I skip the picture for the time being.

I have tried the push "redirect-gateway def1" on my server. The option finds its way into /cf/conf/config.xml and /var/etc/openvpn_server0.conf, but nothing reaches the pfSense where I have the OpenVPN client. I guess I would see some change when I look in "Diagnostics-Routes"?

The temporary "fix" which has solved my problem is to do what you told me not to do. ;-) I have added three routes on the WAN-interface on the OpenVPN client:

0.0.0.0/1 to the VPN-interface
128.0.0.0/1 to the VPN-interface
<my.openvpn.server.address>to the real gatewayaddress, which the interface got from DHCP

Now everything flows through the tunnel, just like I want it to do.

I see two things on my todo-list:
1. Try to find out why redirect-gateway doesn't work
2. Test the current setup in a "live" environment

Thanks for your help. Now I have a much better understanding of how, at least some parts of, OpenVPN ticks.

/Roger</my.openvpn.server.address>

[GruensFroeschli]

Yes you should definitly see a change in the remotes routing table,

The problem with adding this entries manually is just that if the tunnel goes down your remote side still have this entries in the table, and if the openVPN process would add them they would be removed as soon as the tunnel goes down.

I suppose you use a preshared key for your setup?
You could try to use a PKI. I'm not sure if the redirect works with a shared key setup since i never tried it. (but i think it should work)

[bjorktorp]

Yes, I understand the static route problem. It is kind of acceptable for now.

Yes, I use PSK. Thanks for the hint about PKI. I hope to have time to look into it some time next week.

/Roger