Re: IPSEC bringing down networking 1.1
Hi, On Tue, 05.01.2010 at 12:44:49 -0800, Jeff Simmons jsimm...@goblin.punk.net wrote: fw:$ netstat -nr tip: netstat -rnf encap results elided Encap: Source Port Destination Port Proto SA(Address/Proto/Type/Direction) expected ecap routes elided 0/00 0/00 0 gatewayIP/50/use/in 0/00 0/00 0 gatewayIP/50/require/out I've seen this routing entry, too, only _immediately_ after connect, and am *very* interested in talking to qualified people to solve this issue. Imho, this issue has nothing to do with Sonicwall or Cisco. Now, if that means what I think it means, You think correctly. -- Kind regards, --Toni++
Re: IPSEC bringing down networking 1.1
On Saturday 09 January 2010 08:57, Toni Mueller wrote: Hi, On Tue, 05.01.2010 at 12:44:49 -0800, Jeff Simmons jsimm...@goblin.punk.net wrote: fw:$ netstat -nr tip: netstat -rnf encap results elided Encap: Source Port Destination Port Proto SA(Address/Proto/Type/Direction) expected ecap routes elided 0/00 0/00 0 gatewayIP/50/use/in 0/00 0/00 0 gatewayIP/50/require/out I've seen this routing entry, too, only _immediately_ after connect, and am *very* interested in talking to qualified people to solve this issue. Imho, this issue has nothing to do with Sonicwall or Cisco. Now, if that means what I think it means, You think correctly. -- Jeff Simmons jsimm...@goblin.punk.net Simmons Consulting - Network Engineering, Administration, Security You guys, I don't hear any noise. Are you sure you're doing it right? -- My Life With The Thrill Kill Kult
Re: IPSEC bringing down networking 1.1
Apologies for the previous empty message. On Saturday 09 January 2010 08:57, Toni Mueller wrote: Hi, On Tue, 05.01.2010 at 12:44:49 -0800, Jeff Simmons jsimm...@goblin.punk.net wrote: results elided Encap: Source Port Destination Port Proto SA(Address/Proto/Type/Direction) expected ecap routes elided 0/00 0/00 0 gatewayIP/50/use/in 0/00 0/00 0 gatewayIP/50/require/out I've seen this routing entry, too, only _immediately_ after connect, and am *very* interested in talking to qualified people to solve this issue. Imho, this issue has nothing to do with Sonicwall or Cisco. In my case, it's definitely the Sonicwall (partly, the Cisco doesn't seem to be involved). What happens is, we set up a VPN and everything proceeds normally for anywhere from about 4 to 9 hours. Then the SonicWall suddenly, for no discernable reason, sends the following down the pipe: 15:36:26.089180 B.B.B.B.isakmp A.A.A.A.isakmp: [udp sum ok] isakmp v1.0 ex change QUICK_MODE cookie: a2e097b5de0095ba-5ffb617eaf801be5 msgid: f3c98789 len: 172 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 S PI: 0xd4524377 payload: TRANSFORM len: 32 transform: 1 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 0e10 attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute ENCAPSULATION_MODE = TUNNEL attribute KEY_LENGTH = 128 payload: NONCE len: 24 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 [ttl 0] (id 1, len 200) 15:36:26.089370 A.A.A.A.isakmp B.B.B.B.isakmp: [udp sum ok] isakmp v1.0 ex change INFO cookie: a2e097b5de0095ba-5ffb617eaf801be5 msgid: 043ce92b len: 64 payload: HASH len: 24 payload: NOTIFICATION len: 12 notification: INVALID ID INFORMATION [ttl 0] (id 1, len 92) So A.A.A.A (OpenBSD) correctly ascertains that this is probably a bad idea, and rejects the proposal. Now, if there's only one connection (i.e. a single host to host, or host to subnet) running between these two gateways, the system handles things, and eventually a correct A.A.A.A initiated proposal goes back, and everything returns to normal. But with three connections, eventually A.A.A.A accepts the proposal, hoses all network connections on the box, and requires an intervention. Unfortunately, this is a high-traffic 24/7/365 in-production firewall/VPN gateway at a client of mine (and the connection to a separate company they do business with), so testing things that may crash the box is frowned on by my clients. I haven't yet been able to catch logs of the actual acceptance of the 0.0.0.0 routes yet. So I really don't know a) what the hell the Sonicwall thinks it's doing, or b) why the OpenBSD box occasionally goes along with it. If you find out anything, I'd appreciate hearing about it. -- Jeff Simmons jsimm...@goblin.punk.net Simmons Consulting - Network Engineering, Administration, Security You guys, I don't hear any noise. Are you sure you're doing it right? -- My Life With The Thrill Kill Kult
IPSEC bringing down networking 1.1
I have a machine that I admin remotely running 4.6 with all the patches. It's a firewall only machine with 6 ethernet interfaces, 4 of which are active, and has been running fine since I upgraded it. It's got a fairly complex pf.conf. Last week I set up a VPN on it to a Sonic Wall appliance. The VPN comes up and works fine, and then somewhere between 4 and 24 hours later the box loses all network connectivity. You can still login via console, and I've been able to get the local people to run some basic commands (ifconfig, netstat, ps, pfctl -s) and everything seems normal (from what I can get from non-technical people over the phone), but none of the interfaces are passing packets. Rebooting solves the problem for the next 4-24 hrs. It's happened several times now. System logs show nothing. I finally got console on this, and found a highly suspicious entry in the routing table: fw:$ netstat -nr results elided Encap: Source Port Destination Port Proto SA(Address/Proto/Type/Direction) expected ecap routes elided 0/00 0/00 0 gatewayIP/50/use/in 0/00 0/00 0 gatewayIP/50/require/out Now, if that means what I think it means, it's obvious why I'm losing all my network connections to and from that box. I'm using a bare-bones ipsec.conf file that only specifies gateways, routes, and aes-sha1 (modp1024 pfs). Works fine (to both a Sonic Wall and a Cisco ASA) for a while, and then this shows up. Any ideas as to what could be causing this? -- Jeff Simmons jsimm...@goblin.punk.net Simmons Consulting - Network Engineering, Administration, Security You guys, I don't hear any noise. Are you sure you're doing it right? -- My Life With The Thrill Kill Kult
