Tunnel some traffic through an OpenVPN server

sergani

Hello,

I'm sure this question has been floating around for like forever, but unfortunately, I'm not able to get an answer to it.

I'm currently implementing a CentOS 5.5 + OpenVPN 2.0.9 server, serving Windows, Mac and Linux clients, and was hoping if someone could help me with the following:

I need to implement the server, such that some traffic is only passed through the VPN server, let that be for example, traffic to IP X.X.X.X and Y.Y.Y.Y only are to be routed through to the VPN server, or otherwise, traffic to ports 12345 and 54321 only to be sent to the VPN server, while all other traffic, to be sent to the client's original default gateway.

Is this in anyway possible, without the need of proxies, tampering with clients' firewalls and such?

I know how to redirect all traffic through the VPN server, but that's not the case as mentioned above.

I would really very much appreciate your help guys, and I hope this to be achieved through OpenVPN, and not through the use of any proxies and such.

///Sergani

janjust

routing traffic for a particular IP is possible, for a particular port is much harder.

On the client side you add 'route X.X.X.X 255.255.255.0'
on the server side you can add

push "route X.X.X.X 255.255.255.0"

or even

push "route X.X.X.X 255.255.255.255"

sergani

Thanks slot for the quick response!

I'll put that to the test shortly and will let you know if I need further help.

I'm assuming I must add the client configuration line as well, correct? I mean as a must.

sergani

Hello...

I seem to have struck a brick wall.

My server is allowing packet forwarding:

[root@testingserver ~]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

I inserted the following into my iptables:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Then I added the following to my server.conf:

push "route A.B.C.D 255.255.255.0"
push "route W.X.Y.Z 255.255.255.0"

... and this in my client's:

route A.B.C.D 255.255.255.0
route W.X.Y.Z 255.255.255.0

I ran Wireshark on both ends, and can actually see my client machine @ 10.8.0.2 trying to speak to A.B.C.D, but on A.B.C.D (yes I have access to), I'm not able to see any packets coming from the server's side, or any side for that matter...

I even tried shutting down my iptables, but to no avail.

What am I missing?

janjust

what does

cat /proc/sys/net/ipv4/ip_forward

give?

on the server , try pinging a remote site using

ping -I 10.8.0.1 A.B.C.D

or perhaps even

ping -I 10.8.0.1 8.8.8.8

finally, if you use

push "route A.B.C.D 255.255.255.0"

then you don't need to use

route A.B.C.D 255.255.255.0

also: that's double; comment out either end.

sergani

Thanks Jan...

Well, here's my output:

[root@testingserver ~]# cat /proc/sys/net/ipv4/ip_forward 
1

Also, for pinging:

[root@testingserver ~]# ping -I 10.8.0.1 A.B.C.D
PING A.B.C.D (A.B.C.D) from 10.8.0.1 : 56(84) bytes of data.
64 bytes from A.B.C.D: icmp_seq=1 ttl=53 time=91.5 ms
64 bytes from A.B.C.D: icmp_seq=2 ttl=53 time=84.2 ms
64 bytes from A.B.C.D: icmp_seq=3 ttl=53 time=83.2 ms
64 bytes from A.B.C.D: icmp_seq=4 ttl=53 time=86.2 ms
64 bytes from A.B.C.D: icmp_seq=5 ttl=53 time=87.8 ms

--- A.B.C.D ping statistics ---
6 packets transmitted, 5 received, 16% packet loss, time 4995ms
rtt min/avg/max/mdev = 83.261/86.640/91.545/2.928 ms

As you can see, all checks out...

I even removed the requested IPs for routing, and edited the server.conf to contain:

push "redirect-gateway"

and removed any traces of the mentioned IPs from both the client's and the server's side.

Is this normal troubleshooting? I'm having this feeling that I'm missing something terribly dumb that would make me slam my head through a wall!! 😃

janjust

ping -I 10.8.0.1 A.B.C.D

works then routing is OK.

However, if

ping A.B.C.D

from the VPN client does not work then there's something odd in your setup.
Post the client log when it is connecting .

Yes this is normal troubleshooting: getting the VPN up and running usually isn't the biggest problem, it's routing traffic that's the killer.

sergani

Ok... so I figured out my mistake...

Apparently it showed in the logs that the IP i was trying to push the routing to, is not correct, and as a wrong subnet mask! so I fixed that, and it's working now fine!

Two things I need to ask your opinion about:
1- This time I'm interconnecting my client and the server from within the same LAN, but note that on the client side, I'm not using a 192.168.1.X IP, but my home IP, so basically it's like I'm accessing the server from outside the network... or am I confused?! I'll be retrying again tomorrow from outside my home (where the server is), and access from the office, and see if there is any difference... there shouldn't be, right?
2- I'm pretty sure I didn't do any bridging stuff before installing the server etc.. yet my connection now is working as I need, with the following:

dev tap
;dev tun

on both client and server!! What is going on? 🙂

Appreciate your help, time and support!

janjust

@1: I'm not following you; if it works from home then it can be made to work from the office as well; be careful when connecting to a server that is on the same LAN in combination with 'redirect-gateway', as you might get unexpected routing results.

Using your (static?) home IP on your client will NOT work when connecting at the office LAN.

@2: if it works because you switched from tun to tap then there's something funny going on. As you've never posted your config files it is impossible to tell what; it is definitely possible to get this working without having to switch to tap.

sergani

Hello Jan,

I'm sorry for the confusion caused. I'll post my cases and what's working and what's not.
But as of now, and this is I'm sure of, "dev tun" and "dev tap" both work for me, client @ office and server @ home! As for testing from within home, I stopped using "redirect-gateway", and was testing some IP addresses only, and achieved what was needed.

I'm currently using "dev tun" as OpenVPN on the iPhone needs that and doesn't run using "dev tap".

My server.conf is as follows:

port 1194
proto udp
dev tun
ca ca.crt
cert testingserver1.crt
key testingserver1.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route X.Y.Z.0 255.255.255.128"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 5

As for my client, I'll post my iPhone at the moment, as I'm far now from my Mac and Windows, but will post those as well soon. I believe I just wasn't able to connect using "dev tun" through Windows, but I'll double check and post that as soon as I can.
iPhone client.ovpn:

client
dev tun
proto udp
remote testing.server.ip 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca "/private/var/mobile/Library/OpenVPN/ca.crt"
cert "/private/var/mobile/Library/OpenVPN/client1.crt"
key "/private/var/mobile/Library/OpenVPN/client1.key"
ns-cert-type server
comp-lzo
verb 5
log-append openvpn.log
up /usr/bin/update-resolv-conf
down /usr/bin/update-resolv-conf

As I said, I'll post my other conf files as soon as I can, but in the meantime, could you help out by pointing out what's the difference between "dev tun" and "dev tap"? I'm kinda lost here, and I tried to understand the difference from the documentation, online and so on, but can't make head nor tail.
Also, I believe they're directly related to bridging and routing mode, and I'm not really sure what's the difference.

Any help or pointers would be highly appreciated.

janjust

what's the difference between "dev tun" and "dev tap"? I'm kinda lost here, and I tried to understand the difference from the documentation, online and so on, but can't make head nor tail.
Also, I believe they're directly related to bridging and routing mode, and I'm not really sure what's the difference.

'tun' mode is often referred to as 'routing' mode; in 'tun' mode the client and server form a point-to-point network, over which only IP traffic can flow.
'tap' mode is used to pass full Ethernet frames between client and server. A special case of 'tap' mode is bridging, where the tap adapter and a local network interface are bridged: all packets which arrive on one interface are automatically copied over to the other, and vice versa.