0

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 192.168.100.0/24 and 192.168.200.0/24
- OpenVPN works with roadwarrior configuration (client1 can ping the internal IP of IPCop 192.168.100.0 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?

Improve this question
4
  • 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, 2010 at 15:17
  • I'm using OpenVPN+TUN to ping 192.168.100.70 from 192.168.200.5, 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, 2010 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, 2010 at 16:04
  • I wrote in the answer section because the formatting code
    – Emilio
    Feb 4, 2010 at 16:18

3 Answers 3

Reset to default
1

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 192.168.100.4/24 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.

Improve this answer
1

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

Improve this answer
0

This is the 

ipcop# ip route  
10.159.19.2 dev tun0  proto kernel  scope link  src 10.159.19.1  
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.2    
10.159.19.0/24 via 10.159.19.2 dev tun0  
192.168.200.0/24 dev eth1  proto kernel  scope link  src 192.168.200.2  

ipcop# route -n
Kernel IP routing table  
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface  
10.159.19.2     0.0.0.0         255.255.255.255 UH    0      0        0 tun0  
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0  
10.159.19.0     10.159.19.2     255.255.255.0   UG    0      0        0 tun0  
192.168.200.0   0.0.0.0         255.255.255.0   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  
10.159.19.5     0.0.0.0         255.255.255.255 UH    0      0        0 tun0  
10.159.19.1     10.159.19.5     255.255.255.255 UGH   0      0        0 tun0  
192.168.100.0   10.159.19.5     255.255.255.0   UG    0      0        0 tun0  
192.168.200.0   0.0.0.0         255.255.255.0   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 (192.168.200.0/24).

Improve this answer
6
  • 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 10.159.19.0/24 (I guess) to the client for the TUN connection, but the client has also an assigned IP in the 192.168.200.0/24 subnet. Am I right? Why the traffic to the 192.168.200.0/24 subnet is routed through eth1 anyway?
    – Dan Andreatta
    Feb 4, 2010 at 16:35
  • I think it's normal that IPCop route 192.168.200.0/24 through eth1.. it's the Red Interface. And the 192.168.100.0/24 through eth0, it's the Green Interface. It don't seems wrong to me.
    – Emilio
    Feb 4, 2010 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, 2010 at 17:14
  • BTW, how is the routing table on the client?
    – Dan Andreatta
    Feb 4, 2010 at 17:22
  • but the client doesn't have the same IP. The client has only an external IP (192.168.200.0) 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, 2010 at 17:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .