[Openswan Users] unencrypted l2tp packets

Wed Aug 23 11:51:06 EDT 2006

Ok I am onto something now.. All signs point to iptables.

My working machine uses kernel 2.6.14 my non working machine uses  
2.6.17 there a several change in iptables since then.

With 2.6.17 my esp packets are not matched. 2.6.14 they are.

If i match & mark port 4500 & 500 my VPN works as expected. in  
tcpdump I see packets as follows:

11:43:20.066733 IP defender.myhost.net.ipsec-nat-t >  
cpe-24-31-134-99.maine.res.rr.com.ipsec-nat-t: UDP-encap: ESP 
(spi=0x00ed3f6f,seq=0x1263), length 116
11:43:20.144031 IP defender.myhost.net.ipsec-nat-t >  
cpe-24-31-134-99.maine.res.rr.com.ipsec-nat-t: UDP-encap: ESP 
(spi=0x00ed3f6f,seq=0x1264), length 148
11:43:20.297978 IP cpe-24-31-134-99.maine.res.rr.com.ipsec-nat-t >  
defender.myhost.net.ipsec-nat-t: UDP-encap: ESP 
(spi=0x066f603a,seq=0x110c), length 116

To me this means my packet are ESP inside NAT-T which is fine..  
please tell me if I am wrong.

With 2.6.17 iptables uses xtables and xt_esp I think my problem is  
here and I may move over to the netfilter list.

Thanks

On Aug 22, 2006, at 5:34 PM, Brett Curtis wrote:

> Your help is greatly appreciated.
> On Aug 22, 2006, at 2:16 PM, Paul Wouters wrote:
>
>> On Tue, 22 Aug 2006, Brett Curtis wrote:
>>
>>> Rather then setting proc options in sysctl I echoed them in  
>>> proc... AFAIK
>>> there is no difference. ( do not want to reboot )
>>
>> Yup, that's fine.
>
> Ok
>>
>>> These 'test' rules allow me to connect
>>>
>>> # TESTING RULES #
>>> .......
>>
>> This is not a good test. The decrypted esp packets will *also*  
>> show up
>> as plaintext l2tp packets in the input chain after getting decrypted.
>>
>
> Ok with these rules I noticed port 1701 log in my firewall however  
> a tcpdump showed all traffic going over 4500 as it should.
> So I understand what you are saying there.
>
>> The idea of my rules was to mark all ESP packets. This mark survives
>> decrypting, so then we have l2tp packets with the mark. Since we  
>> allow
>> all packets with the mark with an ACCEPT rule, these get accepted.  
>> Then
>> you should *block* l2tp packets with an append (-A) rule. The  
>> result is
>> that when the l2tp was encrypted, the marked packet will be allowed,
>> but if it came in unencrypted, there is no accept rule for it and it
>> hits the drop rule for l2tp.
>
> Ok I was able to test these rules...
>
> iptables -t mangle -A INPUT --proto esp -j MARK --set-mark 1
> iptables -A INPUT -i eth0 -m mark --mark 1 -j LOG --log-prefix  
> "Mark 1:"
> iptables -A INPUT -i eth0 -m mark --mark 1 -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --dport 1701 -j LOG --log-prefix  
> "L2TP Drop:"
> iptables -A INPUT -i eth0 -p udp --dport 1701 -j DROP
>
> Same as yours just with a bit more logging. Interestingly enough  
> Packets are never marked!
> Fails the same way.. dropping of port 1701.
>
> Seems mark in iptables is working I tested this by marking  
> everything with a source address from my XP machine.
>
> $IPT -t mangle -A INPUT -i $EXTIF -s 24.39.31.52 -j MARK --set-mark 2
> $IPT -A INPUT -i $EXTIF -m mark --mark 2 -j LOG --log-prefix "Match  
> 2:"
>
> and simple ping just to see if match is working as it should..
>
>>
>>> Nothing is ever hitting my Match rule I put logging in and  
>>> nothing comes up
>>> maybe my problem is there..
>>> I also didn't use a match and allowed all esp and still the same  
>>> results...
>>>
>>> not sure if this is valid but I also tried tcpdump -i eth0 esp  
>>> and nothing
>>> showed.. No esp packets.
>>
>> netkey is a bit odd, but I believe for incoming you should see  
>> both encrypted
>> and decrypted packets. I guess you should verify your Windows l2tp  
>> connection
>> definition.
>
> I doubled check the XP client and also tried with OSX.
>>
>> Also, to verify/check windows is using ipsec, you can enable  
>> OAKLEY.LOG
>> debugging and then check to see if it is attempting ipsec or not.
>
> At this point would this log help? I could attach it..
>
> So what i think... my esp packets are not matched and I have _no_  
> idea why.  Ideas anyone?
>
> If folks think I am on the write path I may try to roll back to an  
> older kernel this weekend.
>
> It has been a truly long day and I tend to lose my mind after so  
> much debugging ;) so I will pick this up in the morning.
>
> Thanks again, nice to have someone to bounce off of where as I am  
> the only IT guy at the company.
>
>>
>> Paul
>
> Brett Curtis
> dashnu at gmail.com
> http://teh.sh.nu
>
>
>

Brett Curtis
IT Manager
IW Financial
Office: 207-773-2333 ext 2097
Cell: 207-807-2777

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20060823/f59124a1/attachment.html 