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'm wondering if I have the correct routing setup for an IPsec tunnel. I have control over the IPsec endpoints and the hosts connected to one side. These hosts are connecting to the tunnel so that they have access to the network on the other side of what I will call the IPsec server. I don't have control of the network upstream of this server.

Normally, the IPsec server will not respond to ARP requests for the hosts on the other side of the tunnel. So when a packet arrives for one of my hosts the server gets ARP requests, but the upstream router gets no response, and cannot construct the ethernet frame to send me the packets. If I was using one of the swan stacks, I would have a separate interface, and I'd probably just need to turn on proxyarp, but I'm using NETKEY, which doesn't use a separate interface for the tunnel.

To solve the problem for now, I have added an eth0.5 vlan to the IPsec server, turned on proxyarp for that interface, and added all routes my hosts addresses to that interface so that it will respond to those ARP requests (and will therefore get relevant packets routed to it).

This works, but it feels wrong. What is the correct way to get the upstream router to send me the traffic for these hosts?

Topology:

my-host1--ipsec-hw----------|           |-upstream-host1
                            |           |
my-host2--ipsec-hw---------ipsec-server---upstream-host2
                            |           |
my-host3--ipsec-hw----------|           |-upstream-host3

I have control over ipsec-server, myhosts, and the ipsec-hw. The link between ipsec-server and the upstream-hosts is Ethernet. host1, host2, and host3 may have 192.168.0.1, 192.168.0.2, and 192.168.0.3. ipsec-server has 192.168.0.6-192.168.0.10; it assigns 192.168.0.6 to its eth0, and gives 192.168.0.7 - 192.168.0.10 to my-host1, my-host2, and my-host3.

Problem restatement:

When 192.168.0.1 (upstream-host1) wants to send a packet to 192.168.0.7 (my-host1), it has to construct an Ethernet frame. Upstream-host1's route to 192.168.0.0/24 is on its Ethernet port (with no gateway), so to it uses ARP to find a host on the Ethernet link that owns 192.168.0.7. If it cannot get a MAC to put on the Ethernet header, it can't construct the frame, and cannot send the packet.

share|improve this question
    
I don't see how arps are relevant for routing. I have experience of StrongSWAN (which btw doesnt use it's own interface), and I havent really experienced any (Layer3) problems. –  3molo Mar 23 '12 at 19:11
    
The problem is that the IPsec server is assigned several addresses that are a part of the subnet that the server is on. For instance, the IPsec server may have 192.168.0.10 through 192.168.0.20, and there are other hosts on my network that own other addresses - including my gateway. When any of hosts want to talk to e.g. 192.168.0.15, they have to know how to build the ethernet frame, so they send an arp request to find out who owns it. If my server doesn't speak up, it can't build the ethernet frame. –  Shawn J. Goff Mar 23 '12 at 19:27
    
Could you please add a simple topology, because I understand it as the problem lies in the clients behind what is not the ipsec server side, communicating with hosts on the ipsec servers side (which would be 192.168.0.0/24)? –  3molo Mar 23 '12 at 19:40
2  
I think your "hack" is what you're going to have to stick with. Since your subnets overlap, there's no good way to route the traffic, all the hosts are always going to think the traffic is local. –  Coding Gorilla Mar 23 '12 at 21:00
    
Using any of the first 192.168.0/24, 192.168.1/24 etc is never a good idea. –  3molo Mar 24 '12 at 6:18
show 2 more comments

Your Answer

 
discard

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

Browse other questions tagged or ask your own question.