IPsec tunneling problem: tcpdump and iptables see unencrypted traffic

IPsec tunneling problem: tcpdump and iptables see unencrypted traffic

Post by Jurjen Oska » Mon, 24 May 2004 22:03:39



Hi there,

I'm using linux 2.6.5 and ipsec-tools 0.3.2 on Slackware 9.1. I'm trying
to use IPsec between my (wireless) laptop and my home server. Basically,
it seems to work but tcpdump and iptables see incoming traffic two times:
first the encrypted ESP traffic, and the on the same interface the
same traffic but now unencrypted. This is a problem, since now I can't
filter all traffic except ESP on the interfaces (ARP not counted).

The network layout is as follows:

calvin:
eth0: 192.168.1.1/24, internal wired LAN (switched)
eth1: 10.0.0.150/24, crosscable to an ADSL "modem" (10.0.0.138)
eth2: 192.168.2.1/24, crosscable to an access point (192.168.2.2)
ppp0: 213.84.70.4/32, result of a PPTP connection to 10.0.0.138

tracer:
ath0: 192.168.2.100/24, wireless NIC using madwifi driver

What I saw when issuing "ping -c 1 192.168.1.10" on tracer:
===========================================================
(on calvin:)

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
14:48:56.577595 IP 192.168.2.100 > 192.168.2.1: ESP(spi=0x00000301,seq=0x2b5d)
14:48:56.577595 IP 192.168.2.100 > 192.168.1.10: icmp 64: echo request seq 1
14:48:56.578698 IP 192.168.2.1 > 192.168.2.100: ESP(spi=0x00000201,seq=0x2b21)

3 packets captured
3 packets received by filter
0 packets dropped by kernel

(on tracer:)

tcpdump: listening on ath0
14:48:46.854509 192.168.2.100 > 192.168.2.1: ESP(spi=0x00000301,seq=0x2b5d) (DF)
14:48:46.856588 192.168.2.1 > 192.168.2.100: ESP(spi=0x00000201,seq=0x2b21) (DF)
14:48:46.856588 192.168.1.10 > 192.168.2.100: icmp: echo reply (DF)

3 packets received by filter
0 packets dropped by kernel

What I expected to see:
=======================
I expected only ESP traffic in the tcpdump output.

How I configured IPsec:
=======================
(on calvin:)
flush;
spdflush;

add 192.168.2.1 192.168.2.100 esp 0x201 -m tunnel -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831 -A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;
add 192.168.2.100 192.168.2.1 esp 0x301 -m tunnel -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df -A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;

spdadd 0.0.0.0/0 192.168.2.100/32 any -P out ipsec
           esp/tunnel/192.168.2.1-192.168.2.100/require;
spdadd 192.168.2.100/32 0.0.0.0/0 any -P in ipsec
           esp/tunnel/192.168.2.100-192.168.2.1/require;

(on tracer:)
flush;
spdflush;

add 192.168.2.1 192.168.2.100 esp 0x201 -m tunnel -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831 -A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;

add 192.168.2.100 192.168.2.1 esp 0x301 -m tunnel -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df -A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;

spdadd 0.0.0.0/0 192.168.2.100/32 any -P in ipsec
           esp/tunnel/192.168.2.1-192.168.2.100/require;

spdadd 192.168.2.100/32 0.0.0.0/0 any -P out ipsec
           esp/tunnel/192.168.2.100-192.168.2.1/require;

(This is the exact configuration used. Bonus points if you recognize the keys.
:-) )

What I'm trying to accomplish:
==============================
Since I don't trust WEP I want to use IPsec on my wireless network. To do
that, I have connected the access point to a dedicated interface on calvin
where I can firewall it, and only let through IPsec-protected traffic.
On calvin, the traffic may be decrypted and sent on its way.

Questions:
==========
1. Is the observed behaviour to be expected?
2. Am I doing the right thing here?
3. If not, what should I do to use IPsec on the wireless segment?

Hopefully someone can help me here!

Thanks,
--
Jurjen Oskam

"Avoid putting a paging file on a fault-tolerant drive, such as a mirrored
volume or a RAID-5 volume. Paging files do not need fault-tolerance."-MS Q308417

 
 
 

IPsec tunneling problem: tcpdump and iptables see unencrypted traffic

Post by Jurjen Oska » Mon, 24 May 2004 23:39:10


Hi there,

I'm using linux 2.6.5 and ipsec-tools 0.3.2 on Slackware 9.1. I'm trying
to use IPsec between my (wireless) laptop and my home server. Basically,
it seems to work but tcpdump and iptables see incoming traffic two times:
first the encrypted ESP traffic, and the on the same interface the
same traffic but now unencrypted. This is a problem, since now I can't
filter all traffic except ESP on the interfaces (ARP not counted).

The network layout is as follows:

calvin:
eth0: 192.168.1.1/24, internal wired LAN (switched)
eth1: 10.0.0.150/24, crosscable to an ADSL "modem" (10.0.0.138)
eth2: 192.168.2.1/24, crosscable to an access point (192.168.2.2)
ppp0: 213.84.70.4/32, result of a PPTP connection to 10.0.0.138

tracer:
ath0: 192.168.2.100/24, wireless NIC using madwifi driver

What I saw when issuing "ping -c 1 192.168.1.10" on tracer:
===========================================================
(on calvin:)

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
14:48:56.577595 IP 192.168.2.100 > 192.168.2.1: ESP(spi=0x00000301,seq=0x2b5d)
14:48:56.577595 IP 192.168.2.100 > 192.168.1.10: icmp 64: echo request seq 1
14:48:56.578698 IP 192.168.2.1 > 192.168.2.100: ESP(spi=0x00000201,seq=0x2b21)

3 packets captured
3 packets received by filter
0 packets dropped by kernel

(on tracer:)

tcpdump: listening on ath0
14:48:46.854509 192.168.2.100 > 192.168.2.1: ESP(spi=0x00000301,seq=0x2b5d) (DF)
14:48:46.856588 192.168.2.1 > 192.168.2.100: ESP(spi=0x00000201,seq=0x2b21) (DF)
14:48:46.856588 192.168.1.10 > 192.168.2.100: icmp: echo reply (DF)

3 packets received by filter
0 packets dropped by kernel

What I expected to see:
=======================
I expected only ESP traffic in the tcpdump output.

How I configured IPsec:
=======================
(on calvin:)
flush;
spdflush;

add 192.168.2.1 192.168.2.100 esp 0x201 -m tunnel -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831 -A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;
add 192.168.2.100 192.168.2.1 esp 0x301 -m tunnel -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df -A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;

spdadd 0.0.0.0/0 192.168.2.100/32 any -P out ipsec
           esp/tunnel/192.168.2.1-192.168.2.100/require;
spdadd 192.168.2.100/32 0.0.0.0/0 any -P in ipsec
           esp/tunnel/192.168.2.100-192.168.2.1/require;

(on tracer:)
flush;
spdflush;

add 192.168.2.1 192.168.2.100 esp 0x201 -m tunnel -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831 -A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;

add 192.168.2.100 192.168.2.1 esp 0x301 -m tunnel -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df -A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;

spdadd 0.0.0.0/0 192.168.2.100/32 any -P in ipsec
           esp/tunnel/192.168.2.1-192.168.2.100/require;

spdadd 192.168.2.100/32 0.0.0.0/0 any -P out ipsec
           esp/tunnel/192.168.2.100-192.168.2.1/require;

(This is the exact configuration used. Bonus points if you recognize the keys.
:-) )

What I'm trying to accomplish:
==============================
Since I don't trust WEP I want to use IPsec on my wireless network. To do
that, I have connected the access point to a dedicated interface on calvin
where I can firewall it, and only let through IPsec-protected traffic.
On calvin, the traffic may be decrypted and sent on its way.

Questions:
==========
1. Is the observed behaviour to be expected?
2. Am I doing the right thing here?
3. If not, what should I do to use IPsec on the wireless segment?

Hopefully someone can help me here!

Thanks,
--
Jurjen Oskam

"Avoid putting a paging file on a fault-tolerant drive, such as a mirrored
volume or a RAID-5 volume. Paging files do not need fault-tolerance."-MS Q308417

 
 
 

1. microsoft ipsec problem with linux iptables nat tunnel: problem in isakmp key exchange apparently

Hi,

For the last weeks, i've been debugging a problem with the following setup:

windows 2000 laptop - NAT'ing linux iptables firewall - windows 2000 vpn
server

the vpn solution is standard microsoft ipsec, ESP in tunnel mode
keys are public/private keys based on our company's active directory
(whatever that means).

the many (sometimes) conflicting documents i read about this suggest that it
is possible, under certain circumstances:

- if AH (authentication header) protocol is used, just forget about , not
possible with NAT (not in my case fortunately)
- if ESP is used, it depends if tunnel or transport mode is used.
    for tunnel mode, it should work if client and server agree to do udp
encapsulation (I suppose that they mean that the client and server are NAT-T
compatible).

Our network guys have confirmed me that their solution is indeed NAT-T
compatible

when i try to start a vpn connection while my laptop is behind the nat'ing
firewall, i made the following observations with a network sniffer:

i tried to verify the packet exchange between 2 situations:

1) directly connected, no firewall in between (it works this way)
2)  behind the firewall (does not work).

I noticed (thank you ethereal network sniffer) this:

the first packets that are exchanged seem similar in both cases:

5 packets between client and server, from udp 500 to udp 500
after that 2 fragmented udp packets (i can't see more details about it, not
in ethereal, nor with tcpdump)
then in the 8th packet i see a difference:
this is an isakmp packet (udp 500 to udp 500),

but when the laptop is connected directly, i see in the isakmp part of the
packet,
next payload: key exchange (4), flags: no encryption, no commit, no
authentication

and in the other case (behind firewall),:

next payload: identification (5), encryption, no commit, no authentication

the packet in the ok situation has some other headers like key exchange
payload, nonce payload, certificate request payload, while in the bad packet
, i see none of thease headers (just: encrypted payload: 4432 bytes).

It's as if at that time, the key exhcange is stopped because the NAT'ing
interfered somehow ???

Just for the record, there are NO dropped packets because of firewall
limitations, at least not as far as i could tell.

Any ideas what to do next ?

I'm almost ready to throw in the towel, cause i'm getting buried deep in the
nitty gritty of the ipsec protocol, just thought i'd ask the all-knowing
usenet audience for some ultimate guidance :)

thank you,

Tom.

2. Running a program automatically when switching VCs

3. IPsec tunnel up but no traffic

4. Again, Kde problems

5. (Q) constant traffic as seen by tcpdump

6. Problem: Cannot start the Software Manager in OS 5.0.2

7. tcpdump only sees traffic one-way. Why?

8. Kernel Java support and location of JDK

9. How to set iptables for IPSec tunnel?

10. FreeS/Wan & iptables -- fwd Web traffic thru tunnel

11. IPSEC Howto i can buil IPSec tunnel...

12. IPSec Routing for unencrypted traffix

13. IPSEC tunnel problem