I forwarded a message to the security officer about this issue, but I still haven't been able to narrow down whats happening enough to guarantee its just not a bug. I'm running -CURRENT on one server. Our Internet router/firewall is a 6.1-STABLE system running PF, routing two class C's or a /23 subnet actually. I didn't have any trouble until I put the -CURRENT system on our LAN and attempted to make it a router/firewall system. The route is 64.199.142.240/28 => 64.199.142.60, so I'm merely routing a few IP's at the -CURRENT system uname -a FreeBSD mbfw.mb.rndkc.com 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Aug 20 15:29:02 CDT 2006 root_at_mbfw.mb.rndkc.com:/usr/src/sys/amd64/compile/MBFW amd64 router's ethernet addr: 00:0d:87:e9:c0:40 'vr' driver new -current system's public interface eth addr: 00:16:e6:52:cd:47 'nve' driver After leaving tcpdump running until this happens (which, things run away for 2 to 3 minutes and then stop), I've captured this: 17:42:33.829685 00:0d:87:e9:c0:40 > 00:08:54:b1:45:18, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.142.47.1490: S 3842711808:3842711808(0) ack 2054160385 win 16384 0x0000: 4500 0028 0100 4000 5b06 b8cd 51b0 455c E..(.._at_.[...Q.E\ 0x0010: 40c7 8e2f 0050 05d2 e50b 2100 7a70 0001 _at_../.P....!.zp.. 0x0020: 5012 4000 8330 0000 0715 9e32 ef00 P._at_..0.....2.. 17:42:33.831281 00:16:e6:52:cd:47 > 00:08:54:b1:45:18, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.142.47.1490: S 3842711808:3842711808(0) ack 2054160385 win 16384 0x0000: 4500 0028 0100 4000 5906 bacd 51b0 455c E..(.._at_.Y...Q.E\ 0x0010: 40c7 8e2f 0050 05d2 e50b 2100 7a70 0001 _at_../.P....!.zp.. 0x0020: 5012 4000 8330 0000 P._at_..0.. 17:42:33.832700 00:0d:87:e9:c0:40 > 00:0e:0c:b1:b4:0c, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.142.88.1527: S 199865344:199865344(0) ack 1390346241 win 16384 0x0000: 4500 0028 0100 4000 5b06 b8a4 51b0 455c E..(.._at_.[...Q.E\ 0x0010: 40c7 8e58 0050 05f7 0be9 b400 52df 0001 _at_..X.P......R... 0x0020: 5012 4000 f095 0000 d443 0000 69d9 P._at_......C..i. 17:42:33.833752 00:16:e6:52:cd:47 > 00:0e:0c:b1:b4:0c, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.142.88.1527: S 199865344:199865344(0) ack 1390346241 win 16384 0x0000: 4500 0028 0100 4000 5906 baa4 51b0 455c E..(.._at_.Y...Q.E\ 0x0010: 40c7 8e58 0050 05f7 0be9 b400 52df 0001 _at_..X.P......R... 0x0020: 5012 4000 f095 0000 P._at_..... 17:42:33.851227 00:0d:87:e9:c0:40 > 00:50:04:60:34:fd, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.142.148.1918: S 1499637248:1499637248(0) ack 830603265 win 16384 0x0000: 4500 0028 0100 4000 5b06 b868 51b0 455c E..(.._at_.[..hQ.E\ 0x0010: 40c7 8e94 0050 077e 5962 a600 3182 0001 _at_....P.~Yb..1... 0x0020: 5012 4000 d0b6 0000 0050 4f20 0001 P._at_......PO... 17:42:33.852111 00:16:e6:52:cd:47 > 00:50:04:60:34:fd, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.142.148.1918: S 1499637248:1499637248(0) ack 830603265 win 16384 0x0000: 4500 0028 0100 4000 5906 ba68 51b0 455c E..(.._at_.Y..hQ.E\ 0x0010: 40c7 8e94 0050 077e 5962 a600 3182 0001 _at_....P.~Yb..1... 0x0020: 5012 4000 d0b6 0000 P._at_..... 17:42:33.854137 00:0d:87:e9:c0:40 > 00:04:5f:40:0d:2b, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0100 4000 5b06 b714 51b0 455c E..(.._at_.[...Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 _at_....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 0000 0000 0000 P._at_.o......... 17:42:33.854177 00:16:e6:52:cd:47 > 00:0d:87:e9:c0:40, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0100 4000 5906 b914 51b0 455c E..(.._at_.Y...Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 _at_....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 P._at_.o... 17:42:33.854338 00:0d:87:e9:c0:40 > 00:04:5f:40:0d:2b, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0cb6 0000 5806 ee5e 51b0 455c E..(....X..^Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 _at_....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 03f3 e59a 3200 P._at_.o.......2. 17:42:33.854365 00:16:e6:52:cd:47 > 00:0d:87:e9:c0:40, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0cb6 0000 5606 f05e 51b0 455c E..(....V..^Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 _at_....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 P._at_.o... I'm watching this on the -current system's public interface and on the router's LAN facing interface. I suppose the first odd thing is why or how is my switch is showing the -current system's public/LAN facing interface this SYN packet that isn't destined for it. Even worse, however, is the -current's nve interface duplicates these packets - and where is the 81.176.69.92 IP address coming from? The packets occur often and from different IP addresses. I can't tell if the first SYN packet in is actually valid or not, but since these max out a 100mb connection, you can imagine that our main firewall/router's LAN interface is maxing out the CPU (swi1: net has used 545 hours of CPU time and irq23: vr0 588 hours). The -current system is similar with the nve driver. Has anyone seen this kind of behavior? Do I have some kind of weird viral thing happening or a switch problem? The switch has been really stable for us - a Cisco 4003 with 68 ports... I just haven't seen anything like this before - getting a SYN flood from all kinds of addresses and yet if I watch the public router/firewall interface, I only have outbound packets from the network. Sorry if I'm posting to the wrong list, but this only started occuring when we added this -current server to our network... I'm just wondering if there could be some odd behavior with the updates to the nve driver? Thanks, D -- Derrick T. Woolworth R&D Technology, LLC. http://www.rndtechnology.comReceived on Sun Aug 20 2006 - 21:28:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:59 UTC