[Openswan Users] seeing a mix of TCP and ESP traffic. openswan to openswan

[Ryan McLeod]

I looked in /var/log/messages and all it seems to record is that there's a
change to a config file. /var/log/auth.log shows each step of the
establishment and what its doing, but it doesn't seem to be repeating itself
in that regard. I cant say i know entirely what to look for, in terms of a
bouncing connection. ipsec auto --status doesnt have much more either than
just the establishment of the connection.

In the ipsec config file i've set plutodebug="all"

Thanks Paul,

Ryan

On Fri, Jul 16, 2010 at 1:14 PM, Paul Wouters <paul at xelerance.com> wrote:

> On Fri, 16 Jul 2010, Ryan McLeod wrote:
>
> You can only be leaking packets if your IPsec tunnel continiously bounces
> up and down.
> This should be apparent in the normal logs. That should be fixed.
>
> The stack itself cannot possibly be leaking packets if a policy has been
> negotiated
> and put in place.
>
> Paul
>
>  Date: Fri, 16 Jul 2010 13:00:55 -0400
>> From: Ryan McLeod <r.mcleod20 at gmail.com>
>> To: Paul Wouters <paul at xelerance.com>
>> Subject: Re: [Openswan Users] seeing a mix of TCP and ESP traffic.
>> openswan to
>>      openswan
>>
>>
>> I've stuck a virtual machine in the middle of my openswan to openswan
>> IPSec vpn. Aside from ESP traffic I do see the occasional TCP
>> packet. Ultimately I would like to see only ESP traffic (which is the case
>> for openswan to Cisco ASA). These tcp packets are marked with
>> true source and destination IPs: 10.10.10.2 and 192.168.1.5. The wireshark
>> info column says for one of them: search-agent > 46687 [SYN,
>> ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS. Other TCPs start with: 46687 >
>> search agent. Andhave different flags: psh ack, fin ack, etc.
>>
>> I've tried adding iptables -A OUTPUT -j DROP && iptables -A INPUT -j DROP
>> as sort of a deny any any, but that hasnt really worked. i've
>> also tried -P instead of -A for those rules.
>>
>> Any suggestion, insight on where to take this is appreciated.
>>
>> Ryan
>>
>> On Wed, Jul 14, 2010 at 3:53 PM, Ryan McLeod <r.mcleod20 at gmail.com>
>> wrote:
>>      So sniffing on openswan 1 still. For 1 imcp there are 5 packets.
>> First is an ICMP request, then an ESP(request as its coming
>>      from the other openswan device), an ICMP request, an ESP(reply, going
>> to the other openswan device), and then an icmp reply.
>>
>>      Ryan
>>
>>
>> On Wed, Jul 14, 2010 at 3:39 PM, Paul Wouters <paul at xelerance.com> wrote:
>>      On Wed, 14 Jul 2010, Ryan McLeod wrote:
>>
>>      It's just the order ill see them in. Right now my net cat send is
>> failing, as it goes over an asa, which likes to
>>      drop things after a reload.
>>      So i see a tcp, an esp, 2 tcp, an esp, a tcp, 2 arps, a tcp, an esp,
>> then a tcp, and then the connection closes.
>>
>>      I was thinking along the lines of: an esp packet would come in, and
>> get decrypted so I would see one tcp per each
>>      esp coming in. Ultimately
>>      what i want is all traffic between these two encrypted.
>>
>>      But basically what you're saying is what i am seeing is normal?
>>
>>
>> No, it does not look normal.
>>
>> I don't know what is happening. I'd recommend using ping and ensuring you
>> send a known
>> amount of packets. netcat might start retransmitting etc.
>>
>> Paul
>>
>>
>>
>> On Wed, 14 Jul 2010, Ryan McLeod wrote:
>>
>>
>>      I've got two ubuntu vms testing openswan to openswan in a site to
>> site configuration, with a host on each side.
>>
>>      Host 1 ------------------
>> Openswan1==tunnel==Openswan2-----------------Host2
>>      192.168.1.5      x.x1.1    11.11.11.1         11.11.11.2
>> 10.10.10.1        10.10.10.2
>>
>>      When i send data via netcat from Host2 to Host1, im sniffing with
>> wireshark on 11.11.11.1 on the openswan1 machine. And what
>>      i'll see is an ESP
>>      packet for 11.11.11.2 to 11.11.11.1 then two TCP packet that are
>> 10.10.10.2 to 192.168.1.5. It's not in a 1 by one manner.
>>      There will often be
>>      two TCP then one ESP packets in the stream.
>>
>>      Is this behavour normal? I would expect all the traffic to be seen as
>> encrypted ESP data.
>>
>>
>> With NETKEY, you will see with tcpdump:
>> - outgoing unencrpyted packets
>> - incoming encrypted packets
>> - incoming decrypted packets
>>
>> You will not see outgoing encrypted packets.
>>
>> I dont understand your 2-1 mapping, unless you are counting the
>> incoming encrypted + decryped as 2 packets instead of 1.
>>
>> Paul
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20100716/0221a1c9/attachment.html