Hosting Provided By

linux-ipsec: privately-numbered subnets behind linux-ipsec gateways

From: John S. Denker <jsd(at)research.att.com>
Date: Mon Jan 25 1999 - 15:01:42 EST

Consider a network of the type shown in this famous diagram from vpn.how:
> S======G------M........N-------H======T
where S and T are client machines, G and H are security gateways, and M and N are the edges of the public cloud.

The documentation also says

>1. [...] Test that machines in S can ping machines in T (not just that

OK. So much for reading the directions.

Now it turns out there are a number of reasons why it might be nice to have the rightmost subnet (the one shared by H and T) to be numbered in such a way that typical public machines such as M and N would have no clue about how to route traffic with such numbers.

Once the IPSEC tunnel is up, we would not expect to see any public traffic with these private numbers; all such numbers would be securely encapsulated. All we would see would be protocol-50 traffic between G and H.

So the question arises: can the freeswan system handle this? I am telling it enough routing information in /etc/ipsec-auto that it *ought* to be able to route the encapsulated traffic. When G and H are directly connected the tunnel works fine. But when G and H have to talk via the cloud, I can't get it to come close to working, and I suspect it is misrouting the setup packets. Specifically, tcpdump doesn't see any IP packets at all coming out of G during the time when G says it is doing things like
>102 OAKLEY_MAIN_I_1: initiate
>402 OAKLEY_MAIN_I_1: retransmission

Do you need help?

...........

Suggestion: It would be nice to have documentation and testing tools that can handle the case of privately-numbered subnets behind tunnels.

Request: If anybody has experience with this, please let me know.

Thanks --- jsd Received on Mon Jan 25 20:13:41 1999

Contemporary messages sorted: [ By Date ] [ By Thread ] [ By Subject ] [ By Author ] [ By messages with attachments ]

This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 12:59:29 EDT