[Openswan Users] seeing a mix of TCP and ESP traffic. openswan to openswan
r.mcleod20 at gmail.com
Fri Jul 16 13:53:02 EDT 2010
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"
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
> and put in place.
> 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
>> 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.
>> On Wed, Jul 14, 2010 at 3:53 PM, Ryan McLeod <r.mcleod20 at gmail.com>
>> 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.
>> 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.
>> 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 ------------------
>> 192.168.1.5 x.x1.1 126.96.36.199 188.8.131.52
>> 10.10.10.1 10.10.10.2
>> When i send data via netcat from Host2 to Host1, im sniffing with
>> wireshark on 184.108.40.206 on the openswan1 machine. And what
>> i'll see is an ESP
>> packet for 220.127.116.11 to 18.104.22.168 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users