PSK(shared key) and PKI, forcing trafic with push setting - sit-to-sit
-
Mjew my lords
Im working on setting up a pfsense that will act server for 5 off-site using pfsense for the off-sites to.
I've successfully setup the pfsense-server and 2 clients with openvpn using shared key setup, ping and everything works like a charm. But, i want to route all trafic trough the openvpn tunnel from the offsites.
Is this possible using share key? I can't get it to work using any off the push options, push "redirect-gateway def1" do nothing.
I'm force to use PKI in order to use the push options?
EDIT: this guys said that in order to push options you have to use PKI, but is it true? http://forum.pfsense.org/index.php/topic,9624.msg54938.html#msg54938
-
You should read this thread:
http://forum.pfsense.org/index.php/topic,6056.0.htmlYes you need to use a PKI to be able to use pushes.
This includes the "redirect-gateway def1".But you dont need a PKI to redirect all traffic over your tunnel.
If you read up on http://openvpn.net/index.php/documentation/manuals/openvpn-20x-manpage.html
you will find:–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.
To solve this with a shared key setup you basically add three route entries to the tunnel config.
a /32 entry for the remote end of the tunnel
and 0.0.0.0/1 and 128.0.0.0/1 for the other side of the tunnel.–route network/IP [netmask] [gateway] [metric]
Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close.This option is intended as a convenience proxy for the route(8) shell command, while at the same time providing portable semantics across OpenVPN's platform space.
netmask default – 255.255.255.255
gateway default -- taken from --route-gateway or the second parameter to --ifconfig when --dev tun is specified.
The default can be specified by leaving an option blank or setting it to "default".
The network and gateway parameters can also be specified as a DNS or /etc/hosts file resolvable name, or as one of three special keywords:
vpn_gateway -- The remote VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).
net_gateway -- The pre-existing IP default gateway, read from the routing table (not supported on all OSes).
remote_host -- The --remote address if OpenVPN is being run in client mode, and is undefined in server mode.
-
You should read this thread:
http://forum.pfsense.org/index.php/topic,6056.0.htmlYes you need to use a PKI to be able to use pushes.
This includes the "redirect-gateway def1".But you dont need a PKI to redirect all traffic over your tunnel.
If you read up on http://openvpn.net/index.php/documentation/manuals/openvpn-20x-manpage.html
you will find:–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.
To solve this with a shared key setup you basically add three route entries to the tunnel config.
a /32 entry for the remote end of the tunnel
and 0.0.0.0/1 and 128.0.0.0/1 for the other side of the tunnel.–route network/IP [netmask] [gateway] [metric]
Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close.This option is intended as a convenience proxy for the route(8) shell command, while at the same time providing portable semantics across OpenVPN's platform space.
netmask default – 255.255.255.255
gateway default -- taken from --route-gateway or the second parameter to --ifconfig when --dev tun is specified.
The default can be specified by leaving an option blank or setting it to "default".
The network and gateway parameters can also be specified as a DNS or /etc/hosts file resolvable name, or as one of three special keywords:
vpn_gateway -- The remote VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).
net_gateway -- The pre-existing IP default gateway, read from the routing table (not supported on all OSes).
remote_host -- The --remote address if OpenVPN is being run in client mode, and is undefined in server mode.
I'm sorry, but i don't get it. Im using "10.0.1.0/24" in the "Remote network" field on the client, which is the LAN on the master pfsense machine. I've then added a custom route in the custom field "route 10.0.3.0 255.255.255.0" for the other off-sites networks so that they can talk.
I've tested to add "route 0.0.0.0 128.0.0.0;route 128.0.0.0 128.0.0.0" in the custom field of both to server and clients, but no luck.
I understand that you can't use the –redirect-gateway option that you normaly pushes with PKI, so you have to add the routes "manualy" in the openvpn config.
-
You dont add route entries on both sides.
Think of it as if you would edit the routing table manually.
–> You only do it on the client side if you want to redirect all traffic on the client side.x.x.x.x is the public remote end of your tunnel.
y.y.y.y is your WAN gateway
z.z.z.z is the other side of the VPN-tunnel.route x.x.x.x 255.255.255.255 y.y.y.y
route 0.0.0.0 128.0.0.0 z.z.z.z
route 128.0.0.0 128.0.0.0 z.z.z.zBut really you could have read that out of the man-page i copied for you.
-
You dont add route entries on both sides.
Think of it as if you would edit the routing table manually.
–> You only do it on the client side if you want to redirect all traffic on the client side.x.x.x.x is the public remote end of your tunnel.
y.y.y.y is your WAN gateway
z.z.z.z is the other side of the VPN-tunnel.route x.x.x.x 255.255.255.255 y.y.y.y
route 0.0.0.0 128.0.0.0 z.z.z.z
route 128.0.0.0 128.0.0.0 z.z.z.zBut really you could have read that out of the man-page i copied for you.
Ok, ive tried everything now… Im stuck in an evil thought-loop. I must misunderstand you in some of the networks. I run the test environment in vmware fusion.
writepid /var/run/openvpn_server0.pid
#user nobody
#group nobody
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
dev tun
proto tcp-server
cipher BF-CBC
up /etc/rc.filter_configure
down /etc/rc.filter_configure
ifconfig 10.0.8.1 10.0.8.2
lport 1194
route 10.0.2.0 255.255.255.0
secret /var/etc/openvpn_server0.secret
floatThis is my openvpn_server0.conf file.
writepid /var/run/openvpn_client0.pid
#user nobody
#group nobody
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
dev tun
proto tcp-client
cipher BF-CBC
up /etc/rc.filter_configure
down /etc/rc.filter_configure
remote 192.168.0.251 1194
lport 1194
ifconfig 10.0.2.2 10.0.2.1
route 10.0.1.0 255.255.255.0
secret /var/etc/openvpn_client0.secret
route 10.0.1.0 255.255.255.255 192.168.0.1
route 0.0.0.0 128.0.0.0 10.0.2.1
route 128.0.0.0 128.0.0.0 10.0.2.1And this is my client. Both the client and the server are connected by "bridge-technology" to the office test network that uses 192.168.0.0/24, and 192.168.0.1 is the default gateway for both.
-
Can you draw a diagram of what IP-range is where?
I'm a bit confused.Mostly about this part:
server: ifconfig 10.0.8.1 10.0.8.2
client: ifconfig 10.0.2.2 10.0.2.1How are the server and the client supposed to communicate with each other if they dont have a common "transfer-subnet"?
what is the 10.0.1.0 subnet? where is 192.168.0.1? should 10.0.2.x be your transfer-subnet?
-
Can you draw a diagram of what IP-range is where?
I'm a bit confused.Mostly about this part:
server: ifconfig 10.0.8.1 10.0.8.2
client: ifconfig 10.0.2.2 10.0.2.1How are the server and the client supposed to communicate with each other if they dont have a common "transfer-subnet"?
what is the 10.0.1.0 subnet? where is 192.168.0.1? should 10.0.2.x be your transfer-subnet?
192.168.0.0/24 = WAN for both server and client, thus 192.168.0.1 is both their default gateway.
10.0.8.0/24 = "Address pool" setting in openvpn
10.0.1.0/24 = server LAN
10.0.2.0/24 = client LANthanks alot for your help!
-
Ok if your two WAN's are in the same subnet you can leave the first route out.
But you seem to have missconfigured something because
server: ifconfig 10.0.8.1 10.0.8.2
client: ifconfig 10.0.2.2 10.0.2.1
is inconsistant.Check your client config so that the line in question will look like ifconfig 10.0.8.2 10.0.8.1
It should just work if you add the two lines
route 0.0.0.0 128.0.0.0
route 128.0.0.0 128.0.0.0to your client config.
-
Ok, ive change the client config to be consistant as you told me.
server config is the same, and my client now look like this:
writepid /var/run/openvpn_client0.pid
#user nobody
#group nobody
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
dev tun
proto tcp-client
cipher BF-CBC
up /etc/rc.filter_configure
down /etc/rc.filter_configure
remote 192.168.0.251 1194
lport 1194
ifconfig 10.0.8.2 10.0.8.1
route 10.0.1.0 255.255.255.0
secret /var/etc/openvpn_client0.secret
route 0.0.0.0 128.0.0.0
route 128.0.0.0 128.0.0.0I've changed the "Interface IP" field on the clients openvpn options and got the result you asked for. I can successfully ping from LAN->LAN thru the tunnel as befor. I've gotten new routes in the diag_routes.php page.
However, running a tracert the trafic stops at 10.0.8.1
note: the 172.16.17.0/24 subnet is vmware network.
-
Did you on the server end also create an AoN entry that NAT's your remote end?
-
Thanks alot for the help! Got it working! You are my hero! :)
-
Glad to hear it works :)
I assume this is a testnetwork.
So your two WAN's are in the same subnet.If you move this into production you will have to add a static route for the WAN of the server.
Something likeroute x.x.x.x 255.255.255.255 y.y.y.y
with x.x.x.x being the WAN of your server and y.y.y.y the gateway of your client.
Otherwise your client does not know how to send the VPN packets to the server after the tunnel is up.
-
Glad to hear it works :)
I assume this is a testnetwork.
So your two WAN's are in the same subnet.If you move this into production you will have to add a static route for the WAN of the server.
Something likeroute x.x.x.x 255.255.255.255 y.y.y.y
with x.x.x.x being the WAN of your server and y.y.y.y the gateway of your client.
Otherwise your client does not know how to send the VPN packets to the server after the tunnel is up.I'll be moving to production within a month. Thanks alot again! :)
