I have a problem with IPCop + zerina OpenVPN.

alt text

My networks are as in figure, and are well configurated:
- IPCop act like firewall between the two lans and
- OpenVPN works with roadwarrior configuration (client1 can ping the internal IP of IPCop through OpenVPN tunnel).

The problem is that client1 can't ping server1, because IPCop+OpenVPN doesn't forward traffic in the internal LAN. I can't use neither of the two OpenVPN forwarding mode:
- I can't use OpenVPN TUN (routing) solution: the lans are isolated and i have no place to route
- I can't use OpenVPN TAP (bridge) solution (maybe in this case the correct solution), because IPCop doesn't support bridging (don't have bridge-utils and clearly doesn't support it).

Any solution? Or i must move the OPenVPN server in another internal server that can bridge (naturally tuning IPCop to permit OpenVPN traffig to the new VPN server). Are there simplier solution without moving services?

  • I do not really understand the question. To use OpenVPN you have to use either TAP or TUN. What are you using? what interfaces do you see with ifconfig? Could it be a firewall issue? Did you enable/allow the traffic between the two subnets? – Dan Andreatta Feb 4 '10 at 15:17
  • I'm using OpenVPN+TUN to ping from, through OpenVPN tunnel. The OpenVPN works (i see the ICMP coming from IPCop tun0 interface) but the traffic stops at the tun0 interface of IPCop. It doesn't forward on green network. I think that is because: - If I use TUN, it need a "next hop" where route packets. I have no next hop where route - If I use TAP should be the right solution, to bridge tap0 to eth0 (the interface where i have Green network). But TAP doesn't works with IPCop. There is any solution? – Emilio Feb 4 '10 at 15:42
  • What does ip route say on the IPCop/OpenVPN server? BTW, we are using OpenVPN with TUN/UDP to connect two LANs, and we do not see any issue. – Dan Andreatta Feb 4 '10 at 16:04
  • I wrote in the answer section because the formatting code – Emilio Feb 4 '10 at 16:18

OK, new attempt. This is what I think happens.

The packets form the client have the source address 192.168.200.X, goes through the TUN interface (client routing rules), the VPN servers sends it to destination, but the answer goes through eth1, getting lost. You should try and verify all this with tcpdump.

To fix this issue you can probably set the source to be the VPN address, e.g. with a command like

ip route add dev tun0 src 10.169.10.X

However, this is an issue with this test setup, do not expect to have the same issue with the real thing.


the only problem is that server1 has no route for sendind the answer to client1 just add as a route for server1 to the network and server1 should be able to answer to client1. route add -net gw


This is the

ipcop# ip route dev tun0  proto kernel  scope link  src dev eth0  proto kernel  scope link  src via dev tun0 dev eth1  proto kernel  scope link  src  

ipcop# route -n
Kernel IP routing table  
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UH    0      0        0 tun0   U     0      0        0 eth0   UG    0      0        0 tun0   U     0      0        0 eth1  

I think that the problem is that doesn't have a default gateway, so have no place to route traffic.

The routing table on the client is

client1# route -n  
Kernel IP routing table  
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UH    0      0        0 tun0 UGH   0      0        0 tun0   UG    0      0        0 tun0   U     0      0        0 vboxnet1  

vboxnet1 act like a normal eth interface. It's the interface with the client1 is connected to the Red network (

  • OK, I think I see the problem now. All the traffic for the client goes through eth1, and not tun0. It seems that OpenVPN assign an IP address in the range (I guess) to the client for the TUN connection, but the client has also an assigned IP in the subnet. Am I right? Why the traffic to the subnet is routed through eth1 anyway? – Dan Andreatta Feb 4 '10 at 16:35
  • I think it's normal that IPCop route through eth1.. it's the Red Interface. And the through eth0, it's the Green Interface. It don't seems wrong to me. – Emilio Feb 4 '10 at 16:52
  • You cannot have a client on VPN with the same IP subnet as a local subnet. The packets either go through eth1 or tun0. You need to assign another IP pool for the VPN clients, or have the clients use the VPN-assigned IP address (the 10.159.19.X one) when connecting to the VPN. – Dan Andreatta Feb 4 '10 at 17:14
  • BTW, how is the routing table on the client? – Dan Andreatta Feb 4 '10 at 17:22
  • but the client doesn't have the same IP. The client has only an external IP ( on the red interface, and a VPN IP (10.169.19.X). Look the network of the client like an external network. And I want to ping the internal server1 through tunnel. – Emilio Feb 4 '10 at 17:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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