ICMP Error transmission/response over IPSec tunnels
Tom Judge
Today I looked into why I can not get a traceroute across a IPSec IPIP
tunnel an came across an interesting piece of code. Here is a diagram
of the setup:
[Node A] <-> [Router A] <-{IPSec}-> [Router B] <-> [Node B]
If I traceroute from node A to node B I never see the ICMP packet for
the TTL exceeded generated by router b.
So I did a little digging and found and interesting revision of
sys/netinet/ip_icmp.c. In revision 1.93 it seems ume@ added a check for
the flag M_DECRYPTED in icmp_error() and if it was set do not generate
the icmp error message.
So my questions are:
1) Is this check really required?
2) If it is required what makes it required? Is it a problem in the
icmp transmit path, or is there some other reason?
3) It seems the check originated from the KAME project, as FreeBSD no
longer uses the KAME IPSec implementation is check still required?
I found the same check in the netbsd code, but could not find a similar
check in openbsd (although the openbsd ipsec implementation is some what
different from netbsd and freebsd).
Any information about this would be appreciated as I would like to be
able to do traceroutes across my wan.
Thanks
Tom
_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
Tom Judge
> On Tue, 27 May 2008, Tom Judge wrote:
>
> Hi,
>
>> Today I looked into why I can not get a traceroute across a IPSec IPIP
>> tunnel
>
>
> ...
>> Any information about this would be appreciated as I would like to be
>> able to do traceroutes across my wan.
>
> checked the relevant code lately but if I remember the problem is not
> to be fixed trivially in first place.
>
> You should get a reply back from your Node B though, just not from
> Router B.
>
>
> /bz
>
Hi Bjoern,
Yes we do indeed see a reply from node b. It is good to here that this
is a known issue.
The IPSec configuration is a gif ipip tunnel that is then encrypted with
IPSec using esp in tunnel mode as per the ipsec vpn section in the handbook.
Do you have any more information on the underlying source of the
problem? If so it would help me find the problem. I may setup a small
test network to find this problem this evening time permitting.
Thanks
Tom
PS. Could you pm me a link to your RELENG_7 multi ip jail patchs?
Bjoern A. Zeeb
Hi,
> Today I looked into why I can not get a traceroute across a IPSec IPIP tunnel
I guess not an IPIP tunnel but just IPsec tunnel mode?
...
> Any information about this would be appreciated as I would like to be able to
> do traceroutes across my wan.
The problem has been well known and is on my todo list. I haven't
checked the relevant code lately but if I remember the problem is not
to be fixed trivially in first place.
You should get a reply back from your Node B though, just not from Router B.
/bz
--
Bjoern A. Zeeb Stop bit received. Insert coin for new game.
Bjoern A. Zeeb
Hi,
> Yes we do indeed see a reply from node b. It is good to here that this is a
> known issue.
>
> The IPSec configuration is a gif ipip tunnel that is then encrypted with
> IPSec using esp in tunnel mode as per the ipsec vpn section in the handbook.
1) if you do not need the ipip tunnel because you need an interface
and "link state changes" only go with the IPsec tunnel mode.
2) If you need the gi tunnel on top and routing, use IPsec transport
mode.
(ignore the handbook, try to understand it;)
> Do you have any more information on the underlying source of the problem? If
> so it would help me find the problem. I may setup a small test network to
> find this problem this evening time permitting.
a test network is not a problem. time is.
> PS. Could you pm me a link to your RELENG_7 multi ip jail patchs?
check the latest status report at... for the link:
http://www.freebsd.org/news/status/report-2008-01-2008-03.html#Multi-IPv4/v6/no-IP-jails
--
Bjoern A. Zeeb Stop bit received. Insert coin for new game.
Tom Judge
> On Tue, 27 May 2008, Tom Judge wrote:
>
> Hi,
>
>> Yes we do indeed see a reply from node b. It is good to here that
>> this is a known issue.
>>
>> The IPSec configuration is a gif ipip tunnel that is then encrypted
>> with IPSec using esp in tunnel mode as per the ipsec vpn section in
>> the handbook.
>
> 1) if you do not need the ipip tunnel because you need an interface
> and "link state changes" only go with the IPsec tunnel mode.
>
> 2) If you need the gi tunnel on top and routing, use IPsec transport
> mode.
>
> (ignore the handbook, try to understand it;)
I have 13 nodes in a parital mesh running ospf for routing. It would
not be trivial for me to switch from tunnel to transport mode. Also I
have not tested quagga in when the ipsec is in transport mode, and I
guess I do need interfaces to use with quagga. I may test fixing this
additional overhead, but as they say if it's not broken don't fix it.
>
>> Do you have any more information on the underlying source of the
>> problem? If so it would help me find the problem. I may setup a
>> small test network to find this problem this evening time permitting.
>
> a test network is not a problem. time is.
>
>
Please understand that I was not asking for you to fix this problem just
for some pointers into where to start looking. The reason I ask is that
you seem to know in what region that the error exists and it would be
helpful to me if you could tell me so that I could try to find a
solution to the problem myself. At a guess the code that I need to look
as it in icmp_error() or further down the icmp transmit path (maybe
icmp_reflect or further?).
Thanks again.
Tom
Bjoern A. Zeeb
> Bjoern A. Zeeb wrote:
>> On Tue, 27 May 2008, Tom Judge wrote:
>>
>> Hi,
>>
>>> Yes we do indeed see a reply from node b. It is good to here that this is
>>> a known issue.
>>>
>>> The IPSec configuration is a gif ipip tunnel that is then encrypted with
>>> IPSec using esp in tunnel mode as per the ipsec vpn section in the
>>> handbook.
>>
>> 1) if you do not need the ipip tunnel because you need an interface
>> and "link state changes" only go with the IPsec tunnel mode.
>>
>> 2) If you need the gi tunnel on top and routing, use IPsec transport
>> mode.
>>
>> (ignore the handbook, try to understand it;)
>
> I have 13 nodes in a parital mesh running ospf for routing. It would not be
> trivial for me to switch from tunnel to transport mode. Also I have not
> tested quagga in when the ipsec is in transport mode, and I guess I do need
> interfaces to use with quagga. I may test fixing this additional overhead,
> but as they say if it's not broken don't fix it.
Ok. So basically you have 12 gif tunnels on each node, if it would be
a full mesh. So it's less.
So a) you have two endpoints for the gif tunnel which are your Router
A, Router B endpoint. So the only thing you would need to secure is
your IPIP (gif) tunnel between two nodes (Router A, B). This is what
transport mode is for.
Running a traceroute, the IP stack would need to send the icmp ttl
exceeded packet back via the gif tunnel which then would have to be
encrypted.
To my memory the problem is that this does not work.
You could try to find out at which layer by running tcpdump on the
(external) interface and the gif interfaces and if you have enc0 to
see if/where the icmp possibly shows up.
/bz
--
Bjoern A. Zeeb Stop bit received. Insert coin for new game.
Julian Elischer
I did this by running ng_iface into ng_ksocket(UDP) and
using transport mode for all the UDP packets
I had scripts to do it all, but unfortunately it was at
a previous company.
I allocated a number to each site from 1 to 8 and the endpoints
inside the tunnels were 10.42.ME.YOU 10.42.YOU.ME.
The scripts were identical on each machine, and to add a new machine
I just added it to the list in the script, distributed the new
script, and ran it again on each machine..
>
> /bz