Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am running an OpenVPN server with only one NIC.

This is my current layout:

public.ip > Cisco firewall > lan.ip > OpenVPN server

lan.ip = 192.168.22.70

The Cisco firewall forwards the requests to the oVPN server, thus so far everything works and clients are able to connect.

However, all clients connected should be able to access 3 networks:

lan1: 192.168.200.0 (vpn lan)    > tun0
lan2: 192.168.110.0 (office lan) > eth1 (gw 192.168.22.1)
lan3: 192.168.22.0  (server lan) > eth1 (broadcast network)

So tun0 is mapped to eth1.

Iptables output:

# iptables-save 
# Generated by iptables-save v1.4.2 on Wed Feb 16 14:14:20 2011
*filter
:INPUT ACCEPT [327:26098]
:FORWARD DROP [305:31700]
:OUTPUT ACCEPT [291:27378]
-A INPUT -i lo -j ACCEPT 
-A INPUT -i tun0 -j ACCEPT 
-A INPUT -i ! tun0 -p udp -m udp --dport 67 -j REJECT --reject-with icmp-port-unreachable 
-A INPUT -i ! tun0 -p udp -m udp --dport 53 -j REJECT --reject-with icmp-port-unreachable 
-A FORWARD -d 192.168.200.0/24 -i tun0 -j DROP 
-A FORWARD -s 192.168.200.0/24 -i tun0 -j ACCEPT 
-A FORWARD -d 192.168.200.0/24 -i eth1 -j ACCEPT 
COMMIT
# Completed on Wed Feb 16 14:14:20 2011
# Generated by iptables-save v1.4.2 on Wed Feb 16 14:14:20 2011
*nat
:PREROUTING ACCEPT [302:26000]
:POSTROUTING ACCEPT [3:377]
:OUTPUT ACCEPT [49:3885]
-A POSTROUTING -o eth1 -j MASQUERADE 
COMMIT
# Completed on Wed Feb 16 14:14:20 2011

Yet, clients are unable to ping any ip (including 192.168.200.1, which is the oVPN's IP)

When the machine was directly connected to the internet, with 2 NICs, it was quite simply solved with masquerading and adding static routes in the oVPN client's config.

However, as masquerading won't accept virtual interfaces (eth0:0, etc) I am unable to get masquerading to work again (and I'm not even sure whether I need virtual interfaces).

Thanks.

Edit:

OpenVPN server:

# ifconfig 
eth1      Link encap:Ethernet  HWaddr ba:e6:64:ec:57:ac  
          inet addr:192.168.22.70  Bcast:192.168.22.255  Mask:255.255.255.0
          inet6 addr: fe80::b8e6:64ff:feec:57ac/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6857 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4044 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:584046 (570.3 KiB)  TX bytes:473691 (462.5 KiB)
          Interrupt:14 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:334 errors:0 dropped:0 overruns:0 frame:0
          TX packets:334 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:33773 (32.9 KiB)  TX bytes:33773 (32.9 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.200.1  P-t-P:192.168.200.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ifconfig on a client:

# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:22:64:71:11:56  
          inet addr:192.168.110.94  Bcast:192.168.110.255  Mask:255.255.255.0
          inet6 addr: fe80::222:64ff:fe71:1156/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3466 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1838 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:997924 (974.5 KiB)  TX bytes:332406 (324.6 KiB)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:37847 errors:0 dropped:0 overruns:0 frame:0
          TX packets:37847 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2922444 (2.7 MiB)  TX bytes:2922444 (2.7 MiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.200.30  P-t-P:192.168.200.29  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:689 errors:0 dropped:18 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:468778 (457.7 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:16:ea:db:ae:86  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:704699 errors:0 dropped:0 overruns:0 frame:0
          TX packets:730176 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:520385963 (496.2 MiB)  TX bytes:225210422 (214.7 MiB)

static routes line at the end of the client's config (I've been playing around with the 192.168.200.0 -- (un)commenting to see if anything changes):

route 192.168.200.0 255.255.255.0
route 192.168.110.0 255.255.255.0
route 192.168.22.0 255.255.255.0

route on a vpn client:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.200.29  0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.22.0    192.168.200.29  255.255.255.0   UG    0      0        0 tun0
192.168.200.0   192.168.200.29  255.255.255.0   UG    0      0        0 tun0
192.168.110.0   192.168.200.29  255.255.255.0   UG    0      0        0 tun0
192.168.110.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.110.1   0.0.0.0         UG    0      0        0 eth0

edit:

Weirdly enough, if I set

push "redirect-gateway def1"

in the server config, (and thus routes all traffic through VPN, which is not what I want), it seems to work.

share|improve this question
    
Could you please post an output of ifconfig from your OpenVPN server? Also, a routing table from one of OpenVPN clients would be helpful too. –  Alex Feb 16 '11 at 13:30
    
added in the original post –  Tuinslak Feb 16 '11 at 13:55

2 Answers 2

I see two possible problems here. First, you OpenVPN clients probably do not get static routes to your LAN from OpenVPN config. Next, it looks like your OpenVPN server is not a default gateway for your LAN hosts. So, you should add another rule to iptables to allow packets to route back to your OpenVPN server properly. Something like this:

-A POSTROUTING -o eth1 -j SNAT -s 192.168.200.0/24 -d 192.168.22.0/24 --to-source 192.168.22.70

I assume 192.168.22.70 is a LAN address of your OpenVPN server.

share|improve this answer
    
192.168.22.70 is the lan ip of the vpn server, yes –  Tuinslak Feb 16 '11 at 13:52
    
I've added the static lines in the client configs in the original post. As for your iptables line: iptables: No chain/target/match by that name –  Tuinslak Feb 16 '11 at 13:57
    
You should either add this line to the *nat section of the config you posted above or add -t nat to the list of params if you are adding the rule manually, like this: iptables -A POSTROUTING -t nat -o eth1 -j SNAT -s 192.168.200.0/24 -d 192.168.22.0/24 --to-source 192.168.22.70 –  Alex Feb 16 '11 at 14:05
    
Right, sorry, so I have these two lines at the *nat section: -A POSTROUTING -o eth1 -j MASQUERADE + -A POSTROUTING -s 192.168.200.0/24 -d 192.168.22.0/24 -o eth1 -j SNAT --to-source 192.168.22.70 -- correct? But I'm still unable to ping –  Tuinslak Feb 16 '11 at 14:15
up vote 0 down vote accepted

Apparently VPN was working all the time from outside the office.

It was just not routing anything for people inside the 192.168.110.0 network (office).

vpn.domain.tld was pointing to 192.168.22.70 in the LAN.

By changing vpn.domain.tld to point to the public IP address of the VPN server the problem was resolved weirdly enough.

With public IP address I mean the address that's mapped to the Cisco firewall (91.220.102.x), and all packets are forwarded to the lan IP (192.168.22.70) of the VPN (see the layout in my original post).

VPN is not needed at the office, but as VPN starts as a service on Windows machines, I have not yet been able to control when it should start and when it shouldn't (ideally only when outside of the office -- but that's for later).

Thanks for all the assistance.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.