"BAD ICMP" message

Sebastiaan van Erk sebster at sebster.com
Thu Apr 23 14:37:18 UTC 2009


Hi,

Thanks for the reply.

Actually it is the case that the interface are bridged. Here's a list of 
the entire setup:

em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
mtu 1500
         options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
         ether 00:0c:29:61:2a:4b
         inet 111.111.111.111 netmask 0xfffffff0 broadcast 212.61.136.79
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
mtu 1500
         options=98<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
         ether 00:0c:29:61:2a:55
         inet 10.0.80.77 netmask 0xffffff00 broadcast 10.0.80.255
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
em2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
mtu 1500
         options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
         ether 00:0c:29:61:2a:5f
         inet 10.0.81.77 netmask 0xffffff00 broadcast 10.0.81.255
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
em3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
mtu 1500
         options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
         ether 00:0c:29:61:2a:69
         inet 10.0.82.77 netmask 0xffffff00 broadcast 10.0.82.255
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT> metric 0 
mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
         inet6 ::1 prefixlen 128
         inet 127.0.0.1 netmask 0xff000000
pfsync0: flags=0<> metric 0 mtu 1460
         syncpeer: 224.0.0.240 maxupd: 128
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
1500
         ether f2:f4:c1:45:e7:50
         id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
         maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
         root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
         member: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                 ifmaxaddr 0 port 9 priority 128 path cost 2000000
         member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                 ifmaxaddr 0 port 2 priority 128 path cost 20000
tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 
0 mtu 1500
         ether 00:bd:96:02:00:00
         Opened by PID 1310
carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
         inet 111.111.111.112 netmask 0xfffffff0
         carp: MASTER vhid 1 advbase 1 advskew 0
carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
         inet 10.0.80.74 netmask 0xffffff00
         carp: MASTER vhid 2 advbase 1 advskew 0
carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
         inet 10.0.81.74 netmask 0xffffff00
         carp: MASTER vhid 3 advbase 1 advskew 0
carp3: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
         inet 10.0.82.74 netmask 0xffffff00
         carp: MASTER vhid 4 advbase 1 advskew 0
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33160

em0 is the external interface, em1 is the vpn interface, and em2 and em3 
have production machines on them...

The tap0 is the interface used by openvpn. It is bridged in bridge0 to 
the internal em1 network. Since it is bridged, my feeling says that the 
two VPN clients (10.0.80.4 and 10.0.80.150) should be able to talk 
directly to eachother. I have no idea why my linux box (10.0.80.150) 
thinks it can't directly talk to the other vpn client and talks via the 
gateway instead. I get a lot of these ICMP redirects on tap0:

# tcpdump -ni tap0 icmp
tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
16:32:51.719979 IP 10.0.80.77 > 10.0.80.150: ICMP redirect 10.0.80.4 to 
host 10.0.80.4, length 60

I'm sure I'm doing something wrong somewhere, but I can't quite figure 
it out.

Regards,
Sebastiaan

Max Laier wrote:
> On Thursday 23 April 2009 07:05:54 Sebastiaan van Erk wrote:
>> Apr 23 06:58:38 vpn3 kernel: pf: loose state match: TCP
>> 10.0.80.150:51422 10.0.80.150:51422 10.0.80.4:22 [lo=3150927679
>> high=3150923785 win=692 modulator=0] [lo=0 high=692 win=1 modulator=0]
>> 2:0 A seq=3150927679 (3150927679) ack=0 len=0 ackskew=0 pkts=77:0
>> Apr 23 06:58:38 vpn3 kernel: pf: BAD ICMP 5:1 10.0.80.77 -> 10.0.80.150
>                                             ^
> 
> These are ICMP redirect messages.  This clearly suggests that something is 
> very wrong with your routing.  I assume your netmasks are wrong.  It looks 
> like 10.0.80.77 thinks that 10.0.80.150 can reach 10.0.80.4 directly which is 
> not the case - it needs to route through 10.0.80.77.
> 
>> state: TCP 10.0.80.4:22 10.0.80.4:22 10.0.80.150:51422 [lo=3150927679
>> high=3150923785 win=692 modulator=0] [lo=0 high=692 win=1 modulator=0]
>> 2:0 seq=3150927679
>>
>> I see this message several times and the connection no longer works
>> after that.
>>
>> Does anybody know what's going on and how I can fix it?
> 
> Use separate ip-ranges on either side of the vpn-router or combine vpn-
> endpoints from the same subnet in a bridge interface to allow direct 
> communication between all members in one subnet.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3328 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20090423/ecbe0ced/smime.bin


More information about the freebsd-pf mailing list