On Mon, Mar 01, 2010 at 11:57:41AM +0100, Tony Sarendal wrote: > Good morning misc, > > I upgraded two devices from i386-4.6 to i386-snapshot-feb28. > After the upgrade snapshot boxes are unable to communicate with the 4.6 > devices > when going through ipsec. snapshot-snapshot works fine. > > Everything looks ok except that nothing shows up on enc0 when doing > 4.6<-->snapshot. > Deleting the SA's restores connectiviy, unencrypted of course. > Is this a known issue ?
Yes: http://www.openbsd.org/faq/current.html#20100110 -Otto > > /T > > bmr1.jfa: 212.112.186.174 (4.6) > bmr1.brh: 212.188.183.71 (snapshot) > > --- > bmr1.jfa# ipsecctl -sa | grep 212.188.183.71 > flow esp in from 212.188.183.71 to 212.112.186.174 peer 212.188.183.71 srcid > 212.112.186.174/32 dstid 212.188.183.71/32 type use > flow esp out from 212.112.186.174 to 212.188.183.71 peer 212.188.183.71 > srcid 212.112.186.174/32 dstid 212.188.183.71/32 type require > esp transport from 212.188.183.71 to 212.112.186.174 spi 0x3f91b3c2 auth > hmac-sha2-256 enc aes > esp transport from 212.112.186.174 to 212.188.183.71 spi 0xa797ec1e auth > hmac-sha2-256 enc aes > bmr1.jfa# > > bmr1.brh# ipsecctl -sa | grep 212.112.186.174 > flow esp in from 212.112.186.174 to 212.188.183.71 peer 212.112.186.174 > srcid 212.188.183.71/32 dstid 212.112.186.174/32 type use > flow esp out from 212.188.183.71 to 212.112.186.174 peer 212.112.186.174 > srcid 212.188.183.71/32 dstid 212.112.186.174/32 type require > esp transport from 212.188.183.71 to 212.112.186.174 spi 0x3f91b3c2 auth > hmac-sha2-256 enc aes > esp transport from 212.112.186.174 to 212.188.183.71 spi 0xa797ec1e auth > hmac-sha2-256 enc aes > bmr1.brh# > > bmr1.brh# pfctl -d > pf disabled > bmr1.brh# tcpdump -n -p -i vlan301 host 212.112.186.174 & > [1] 2099 > bmr1.brh# tcpdump: listening on vlan301, link-type EN10MB > bmr1.brh# tcpdump -n -p -i enc0 & > [2] 23922 > bmr1.brh# tcpdump: listening on enc0, link-type ENC > bmr1.brh# > > bmr1.jfa# tcpdump -n -p -i bge0 host 212.188.183.71 & > [1] 443 > bmr1.jfa# tcpdump: listening on bge0, link-type EN10MB > bmr1.jfa# tcpdump -n -p -i enc0 & > [2] 16714 > bmr1.jfa# tcpdump: listening on enc0, link-type ENC > bmr1.jfa# > > > bmr1.jfa# ping 212.188.183.71 > PING 212.188.183.71 (212.188.183.71): 56 data bytes > 11:21:48.081933 (authentic,confidential): SPI 0x007e7833: 212.112.186.174 > > 212.188.183.71: icmp: echo request > 11:21:48.081969 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 15 > len 116 > 11:21:49.085937 (authentic,confidential): SPI 0x007e7833: 212.112.186.174 > > 212.188.183.71: icmp: echo request > 11:21:49.085974 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 16 > len 116 > 11:21:50.095970 (authentic,confidential): SPI 0x007e7833: 212.112.186.174 > > 212.188.183.71: icmp: echo request > 11:21:50.096006 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 17 > len 116 > 11:21:51.106010 (authentic,confidential): SPI 0x007e7833: 212.112.186.174 > > 212.188.183.71: icmp: echo request > 11:21:51.106045 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 18 > len 116 > > bmr1.brh# 10:21:48.102134 esp 212.112.186.174 > 212.188.183.71 spi > 0x007e7833 seq 15 len 116 > 10:21:49.106079 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 16 > len 116 > 10:21:50.116146 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 17 > len 116 > 10:21:51.126213 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 18 > len 116 > > ---- > > bmr1.jfa# grep 212.188.183.71 /etc/ipsec.conf > ike esp transport from 212.112.186.174 to 212.188.183.71 > > bmr1.brh# grep 212.112.186.174 /etc/ipsec.conf > ike esp transport from 212.188.183.71 to 212.112.186.174
