RE: [suse-security] ipsec traffic
Nonetheless, tcpdump registered lots of traffic during the whole night.
So what does it say and how does that compare to e.g. the Pluto logs? Have you tried using tcpdump on the FreeS/WAN machine itself?
Pluto says this:
Sep 12 11:01:52 uhura kernel: klips_debug:gettdb: linked entry in tdb table for hash=175 of SA:esp0x41b4818@<gateA> requested. Sep 12 11:01:52 uhura kernel: klips_debug:gettdb: linked entry in tdb table for hash=230 of SA:tun0x1002@<gateB> requested.
That's what KLIPS says, not Pluto. Set plutodebug to 'all' and see what Pluto says.
tcpdump says this:
11:03:52.085197 62.180.107.34 > <gateA>: ESP(spi=0x041b4818,seq=0x7dc) 11:03:52.086084 62.180.107.146 > <gateB>: ESP(spi=0x7511fb3c,seq=0x936)
Note, <gateA> is the IP-address of the one ipsec-gateway, <gateB> the one from the other ipsec-gateway.
What are the machines 62.180.107.34 and 62.180.107.146, not <gateB> and <gateA> respectively, by chance? Where did you sniff this, on which machine? Have you tried using tcpdump on <gateA> and <gateB>, perhaps specifying the ipsec0 interface (assuming that's the one you use)? If not, do so. Cya, Tobias
On Friday, 13. September 2002 07:45, tobias.reckhard@secunet.com wrote:
Nonetheless, tcpdump registered lots of traffic during the whole night.
So what does it say and how does that compare to e.g. the
Pluto logs? Have you tried using tcpdump on the FreeS/WAN machine itself?
Pluto says this:
Sep 12 11:01:52 uhura kernel: klips_debug:gettdb: linked entry in tdb table for hash=175 of SA:esp0x41b4818@<gateA> requested. Sep 12 11:01:52 uhura kernel: klips_debug:gettdb: linked entry in tdb table for hash=230 of SA:tun0x1002@<gateB> requested.
That's what KLIPS says, not Pluto. Set plutodebug to 'all' and see what Pluto says.
Sep 13 09:20:48 uhura Pluto[9867]: | *time to handle event Sep 13 09:20:48 uhura Pluto[9867]: | event after this is EVENT_SA_REPLACE in 2670 seconds Sep 13 09:20:48 uhura Pluto[9867]: | inserting event EVENT_SHUNT_SCAN, timeout in 120 seconds Sep 13 09:20:48 uhura Pluto[9867]: | next event EVENT_SHUNT_SCAN in 120 seconds -- CU, Christoph
On Friday, 13. September 2002 09:21, egger@mlcomputing.de wrote:
On Friday, 13. September 2002 07:45, tobias.reckhard@secunet.com wrote:
tcpdump says this:
11:03:52.085197 <gateB> > <gateA>: ESP(spi=0x041b4818,seq=0x7dc) 11:03:52.086084 <gateA> > <gateB>: ESP(spi=0x7511fb3c,seq=0x936)
Note, <gateA> is the IP-address of the one ipsec-gateway, <gateB> the one from the other ipsec-gateway.
That's what KLIPS says, not Pluto. Set plutodebug to 'all' and see what Pluto says.
Sep 13 09:20:48 uhura Pluto[9867]: | *time to handle event Sep 13 09:20:48 uhura Pluto[9867]: | event after this is EVENT_SA_REPLACE in 2670 seconds Sep 13 09:20:48 uhura Pluto[9867]: | inserting event EVENT_SHUNT_SCAN, timeout in 120 seconds Sep 13 09:20:48 uhura Pluto[9867]: | next event EVENT_SHUNT_SCAN in 120 seconds
I should notice, that on <gateA> runs FreeSWAN 1.94 and on <gateB> FreeSWAN 1.98. On <gateB> I found this sentence in the documentation (file opportunism.howto): -------- Pluto now looks every 2 minutes for any %holds that it missed. -------- Further in the file CHANGES I found this: -------- The last remnants of the "%hold" bug, which broke 1.93 and 1.94, have (we think) been dealt with. -------- Does that explain the traffic? When I update FreeSWAN on <gateA>, does that prevent pluto doing the EVENT_SHUNT_SCAN's every 2 minutes? -- CU, Christoph
On Friday, 13. September 2002 11:22, egger@mlcomputing.de wrote:
Sep 13 09:20:48 uhura Pluto[9867]: | *time to handle event Sep 13 09:20:48 uhura Pluto[9867]: | event after this is EVENT_SA_REPLACE in 2670 seconds Sep 13 09:20:48 uhura Pluto[9867]: | inserting event EVENT_SHUNT_SCAN, timeout in 120 seconds Sep 13 09:20:48 uhura Pluto[9867]: | next event EVENT_SHUNT_SCAN in 120 seconds
I should notice, that on <gateA> runs FreeSWAN 1.94 and on <gateB> FreeSWAN 1.98.
On <gateB> I found this sentence in the documentation (file opportunism.howto):
-------- Pluto now looks every 2 minutes for any %holds that it missed. --------
Further in the file CHANGES I found this:
-------- The last remnants of the "%hold" bug, which broke 1.93 and 1.94, have (we think) been dealt with. --------
Does that explain the traffic? When I update FreeSWAN on <gateA>, does that prevent pluto doing the EVENT_SHUNT_SCAN's every 2 minutes?
Ok, I solved the traffic problem after updating <gateA> to FreeSWAN 1.98. Does anyone know how to tell pluto to reconfigure the ipsec0 device, when the ip address changes due to a dynamic ip adress (dial up connection) ? Currently I do this by restarting freeswan in the /etc/ppp/ip-up script. Somehow I can't believe that there's no more elegant way to go.... -- CU, Christoph
On Friday, 13. September 2002 11:22, egger@mlcomputing.de wrote:
Sep 13 09:20:48 uhura Pluto[9867]: | *time to handle event Sep 13 09:20:48 uhura Pluto[9867]: | event after this is EVENT_SA_REPLACE in 2670 seconds Sep 13 09:20:48 uhura Pluto[9867]: | inserting event EVENT_SHUNT_SCAN, timeout in 120 seconds Sep 13 09:20:48 uhura Pluto[9867]: | next event EVENT_SHUNT_SCAN in 120 seconds
I should notice, that on <gateA> runs FreeSWAN 1.94 and on <gateB> FreeSWAN 1.98.
On <gateB> I found this sentence in the documentation (file opportunism.howto):
-------- Pluto now looks every 2 minutes for any %holds that it missed. --------
Further in the file CHANGES I found this:
-------- The last remnants of the "%hold" bug, which broke 1.93 and 1.94, have (we think) been dealt with. --------
Does that explain the traffic? When I update FreeSWAN on <gateA>, does that prevent pluto doing the EVENT_SHUNT_SCAN's every 2 minutes?
Ok, I solved the traffic problem after updating <gateA> to FreeSWAN 1.98. Does anyone know how to tell pluto to reconfigure the ipsec0 device, when the ip address changes due to a dynamic ip adress (dial up connection) ? Currently I do this by restarting freeswan in the /etc/ppp/ip-up script. Somehow I can't believe that there's no more elegant way to go.... -- CU, Christoph
participants (2)
-
Christoph Egger -
Reckhard, Tobias