Hey, Paul. I appreciate your response. Do not use leftsourceip= if you specify more then one leftsubnet. Also, > leftsourceip= must be an IP address within the (single) leftsubnet= > > right=12.131.93.13 > > rightsubnets=" 10.50.32.166/32 10.50.32.239/32 10.50.36.4/32 " > > rightsourceip=12.131.93.13 > > The same applies here. >
Good to know, but I don't think it's getting used. We'll clean up the config. > > SAs come up, and we can ping their side. > > > 000 #3166924: "orthooklahoma3937/1x1":4500 STATE_QUICK_I2 (sent QI2, > IPsec SA established); EVENT_SA_REPLACE in 918s; newest IPSEC; eroute > owner; isakmp#3166786; idle; import:admin initiate > > 000 #3166924: "orthooklahoma3937/1x1" esp.815a3ae9@12.131.93.13 > esp.618dd3ad@172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! > ESPmax=4194303B > > 000 #3167825: "orthooklahoma3937/1x2":4500 STATE_QUICK_I2 (sent QI2, > IPsec SA established); EVENT_SA_REPLACE in 1148s; newest IPSEC; eroute > owner; isakmp#3166786; idle; import:admin initiate > > 000 #3167825: "orthooklahoma3937/1x2" esp.73c12328@12.131.93.13 > esp.b76a1e64@172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! > ESPmax=4194303B > > 000 #3165167: "orthooklahoma3937/1x3":4500 STATE_QUICK_I2 (sent QI2, > IPsec SA established); EVENT_SA_REPLACE in 82s; newest IPSEC; eroute owner; > isakmp#3136241; idle; import:admin initiate > > 000 #3165167: "orthooklahoma3937/1x3" esp.33a967a1@12.131.93.13 > esp.72596d49@172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! > ESPmax=4194303B > > 000 #3166787: "orthooklahoma3937/2x1":4500 STATE_QUICK_I2 (sent QI2, > IPsec SA established); EVENT_SA_REPLACE in 891s; newest IPSEC; eroute > owner; isakmp#3166786; idle; import:admin initiate > > 000 #3166787: "orthooklahoma3937/2x1" esp.970dcc23@12.131.93.13 > esp.207c2a70@172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! > ESPmax=4194303B > > 000 #3166964: "orthooklahoma3937/2x2":4500 STATE_QUICK_I2 (sent QI2, > IPsec SA established); EVENT_SA_REPLACE in 602s; newest IPSEC; eroute > owner; isakmp#3166786; idle; import:admin initiate > > 000 #3166964: "orthooklahoma3937/2x2" esp.61180b3@12.131.93.13 > esp.50ff9d05@172.20.109.76 ref=0 refhim=0 Traffic: ESPin=1KB ESPout=1KB! > ESPmax=4194303B > > 000 #3162278: "orthooklahoma3937/2x3":4500 STATE_QUICK_I2 (sent QI2, > IPsec SA established); EVENT_SA_EXPIRE in 437s; isakmp#3136241; idle; > import:admin initiate > > 000 #3162278: "orthooklahoma3937/2x3" esp.e4c24f90@12.131.93.13 > esp.cadf8591@172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! > ESPmax=4194303B > > 000 #3162955: "orthooklahoma3937/2x3":4500 STATE_QUICK_R2 (IPsec SA > established); EVENT_SA_REPLACE in 399s; newest IPSEC; eroute owner; > isakmp#3136241; idle; import:admin initiate > > 000 #3162955: "orthooklahoma3937/2x3" esp.d783e492@12.131.93.13 > esp.1d0a885d@172.20.109.76 ref=0 refhim=0 Traffic: ESPin=42KB ESPout=0B! > ESPmax=4194303B > > 000 #3166786: "orthooklahoma3937/2x3":4500 STATE_MAIN_R3 (sent MR3, > ISAKMP SA established); EVENT_SA_REPLACE in 26486s; newest ISAKMP; nodpd; > idle; import:admin initiate > > > > We have duplicate SAs for some reason -- you can see that for 2x3, not > sure if that matters. > > It should not matter. What seems to have happened is that when you > established the IKE SA, and you were in the process of establishing all > the IPsec SA's, the other end also started doing the same IPsec SA's. > So you ended up with one connection which was initiated by you and > responded to by you. One of them should vanish after a little while. > > Yeah, that's what I thought. They do come and go, but we consistently have two: 000 #439432: "orthooklahoma3937/2x3":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 47s; isakmp#430186; idle; import:admin initiate 000 #439432: "orthooklahoma3937/2x3" esp.16ea20ad@12.131.93.13 esp.6916d827@172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B 000 #449005: "orthooklahoma3937/2x3":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 1873s; newest IPSEC; eroute owner; isakmp#430186; idle; import:admin initiate 000 #449005: "orthooklahoma3937/2x3" esp.523917e3@12.131.93.13 esp.51b2fd1a@172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B ^At the moment, we have two that our side has initiated. Still, as far as I can see, no big deal. Seems to be valid on both sides. > It's the 1x1 SA that's pertinent. We NAT the source and target ips via > PREROUTING and POSTROUTING rules, and I > > can see traffic initiated by the customer hitting PREROUTING but never > hitting POSTROUTING and never leaving the box. > > Are you using the policy matching for ipsec? See: > We don't use policy matching, but we've never had to before. For inbound customer traffic, we PREROUTE to match the config, and then we POSTROUTE to NAT the traffic past our gateway. You can see the pings match the config and disappear. We do this for all our tunnels, so pretty sure it's not that, but correct me if I'm wrong. If it were a iptables error, I'd expect the behavior to be consistent, but it the connection works for a while, and then breaks. It's working now, for example: working: 18:46:43.944652 IP 12.131.93.13.4500 > 172.20.109.76.4500: UDP-encap: ESP(spi=0x760cc9e1,seq=0x6c047), length 100 << Into our gateway 18:46:43.944652 IP 10.50.32.166 > 10.253.1.53: ICMP echo request, id 4, seq 36054, length 40 << Through PREROUTING 18:46:43.944700 IP 10.153.32.166 > 172.20.75.204: ICMP echo request, id 4, seq 36054, length 40 << Through POSTROUTING not working from before: 18:52:14.753803 IP 12.131.93.13.4500 > 172.20.109.76.4500: UDP-encap: << Into our gateway ESP(spi=0x57369ff6,seq=0x14254d), length 100 18:52:14.753803 IP 10.50.32.166 > 10.253.1.53: ICMP echo request, id 2, seq << Through PREROUTING 16669, length 40 << Vanish! >> It's working now, so I don't have any useful xfrm state info to show, but I can produce that when it breaks again. Any more info I can provide? -Dharma
_______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan