Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 3025 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

bogus IPSPOOFING stopping network traffic

benlutgens
Periodically the machine protected by my ASL box loose all connectivity to the outside world. It's temporary usually and completely unexplainable for the most part. I'm able to ping other LAN hosts, but anything that needs to head out the default route just _stops_. The only thing i see in the logs is bogus IPSPOOFING messages, they appear to come from two seperate HW addrs, but various IPS. My windows boxes seem to have the most trouble with this but i've seen it on some of our linux and freebsd workstations and servers as well as our OSX laptops. 

Can anyone give me a clue what might help debug this? My setup basically looks like so:

eth0: The Net
eth1: My Lan 10.0.0.0
eth2: Sep Private net (for webservers and the like) 192.168.100.0

I have another network behind another firewall/router box (linux iptables) on 192.168.0.0/255.255.248.0.

For the most part everything works great except these random stoppages. I am clueless where the problem lies. Any help would be appreciated.


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to emgadmin
    There's tons of them:

    Sep 26 00:01:11 vpn kernel: IP-SPOOFING Drop: IN=eth2 OUT= MAC=ff:ff:ff:ff:ff:ff
    :00:b0[:D]0:61:6e:c7:08:00 SRC=10.0.2.3 DST=10.255.255.255 LEN=259 TOS=0x00 PREC=0
    x00 TTL=128 ID=15963 PROTO=UDP SPT=138 DPT=138 LEN=239

    Sep 26 00:01:11 vpn kernel: UDP Drop: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:2
    1[:D]b:09:e6:08:00 SRC=10.0.3.1 DST=10.255.255.255 LEN=132 TOS=0x00 PREC=0x00 TTL=
    64 ID=0 DF PROTO=UDP SPT=32775 DPT=111 LEN=112

    Sep 26 00:01:41 vpn kernel: UDP Drop: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:2
    1:e3:b7:89:08:00 SRC=10.0.2.201 DST=10.255.255.255 LEN=226 TOS=0x00 PREC=0x00 TT
    L=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=206 

    Note they're all different IPs but same MAC src
  • 0 in reply to benlutgens
    The dropped packets look like harmless broadcast traffic.  Also, the Mac Addresses are different:

    Sep 26 00:01:11 vpn kernel: IP-SPOOFING Drop: IN=eth2 OUT= MAC=ff:ff:ff:ff:ff:ff
    :00: b0[:D]0:61:6e:c7:08 :00 SRC=10.0.2.3 DST=10.255.255.255 LEN=259 TOS=0x00 PREC=0
    x00 TTL=128 ID=15963 PROTO=UDP SPT=138 DPT=138 LEN=239

    Sep 26 00:01:11 vpn kernel: UDP Drop: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00: 00:21[:D]b:09:e6:08  SRC=10.0.3.1 DST=10.255.255.255 LEN=132 TOS=0x00 PREC=0x00 TTL=
    64 ID=0 DF PROTO=UDP SPT=32775 DPT=111 LEN=112

    Sep 26 00:01:41 vpn kernel: UDP Drop: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00: 00:21:e3:b7:89:08 :00 SRC=10.0.2.201 DST=10.255.255.255 LEN=226 TOS=0x00 PREC=0x00 TT
    L=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=206 

    Does both your LAN and DMZ (for your webservers) both lose connectivity?  When it goes down, can you ping the ethernet interface of your astaro box from either network?  How about eth0?  Are you sure all your interfaces are up on astaro when you have the problem?  Any errors or dropped packets show up when you excute an ifconfig on astaro?  Default route still there?  It may be a hardware issue with the nics in your astaro box..
  • 0 in reply to david_hilla
    We have got basically the same trouble here with a mixed windows/macos 9/Macos X network... Mainly when OS9 machines start up, it is impossible for them to access the ASTARO box (impossible to ping it, or use it as a gateway) during 2 minutes or so. Sudently, the box becomes abvailable with no apparent reason. Windows boxes seem unaffected.
    I have got a lot of 

    Oct  3 17:24:29 concerto-800-u kernel: IP-SPOOFING Drop: IN=eth2 OUT= MAC=00:00[:D]1:ee:bd:cf:00:30:65:a7:75:fa:08:00 SRC=192.168.1.27 DST=212.35.96.66 LEN=61 TOS=0x00 PREC=0x00 TTL=255 ID=5483 DF PROTO=UDP SPT=49152 DPT=53 LEN=41 
    Oct  3 17:24:30 concerto-800-u kernel: IP-SPOOFING Drop: IN=eth2 OUT= MAC=00:00[:D]1:ee:bd:cf:00:30:65:a7:75:fa:08:00 SRC=192.168.1.27 DST=212.35.96.66 LEN=61 TOS=0x00 PREC=0x00 TTL=255 ID=5484 DF PROTO=UDP SPT=49152 DPT=53 LEN=41 
    Oct  3 17:24:31 concerto-800-u kernel: IP-SPOOFING Drop: IN=eth2 OUT= MAC=00:00[:D]1:ee:bd:cf:00:30:65:a7:75:fa:08:00 SRC=192.168.1.27 DST=212.35.96.66 LEN=61 TOS=0x00 PREC=0x00 TTL=255 ID=5485 DF PROTO=UDP SPT=49152 DPT=53 LEN=41 

    and

    Oct  3 17:25:05 concerto-800-u kernel: UDP Drop: IN=eth0 OUT= MAC=00:00[:D]1:ee:bd:cd:00:07:95:aa:02:0a:08:00 SRC=192.168.1.136 DST=192.168.1.254 LEN=161 TOS=0x00 PREC=0x00 TTL=128 ID=12107 PROTO=UDP SPT=1033 DPT=1900 LEN=141 
    Oct  3 17:25:05 concerto-800-u kernel: UDP Drop: IN=eth0 OUT= MAC=00:00[:D]1:ee:bd:cd:00:07:95:aa:02:0a:08:00 SRC=192.168.1.136 DST=192.168.1.254 LEN=160 TOS=0x00 PREC=0x00 TTL=128 ID=12108 PROTO=UDP SPT=1033 DPT=1900 LEN=140 
    Oct  3 17:25:05 concerto-800-u kernel: UDP Drop: IN=eth0 OUT= MAC=00:00[:D]1:ee:bd:cd:00:07:95:aa:02:0a:08:00 SRC=192.168.1.136 DST=192.168.1.254 LEN=161 TOS=0x00 PREC=0x00 TTL=128 ID=12109 PROTO=UDP SPT=1033 DPT=1900 LEN=141 
    Oct

    in the logs.

    Very annoying problem...
  • 0 in reply to Antoine Duchateau
    OK... I found the solution to this problem. At least on this site. The troubles come from the fact that the DMZ and the LAN are logically different network but physically the same network. In other words, LAN (eth0:192.168.1.0/24) and DMZ (eth2:192.168.0.0/24) are on the same series of switches. What happens is that packets from LAN are sometimes directed to the DMZ interface (eth2). When this happens, I get a IP-Spoofing drop in the kernel log and traffic stays stuck between client computer and eth2 if. Client computer/switches never understand packet should be routed to eth0 instead of eth2. I see two sollutions: either get rid of the DMZ for the time neing or physically separate networks from each other.

    Is this a normal behaviour or should the firewall act more cleverly ?
     
     [size="1"][ 03 October 2002, 12:20: Message edited by: Antoine Duchateau ][/size]
  • 0 in reply to Antoine Duchateau
    Hi benlutgens

      
     Is this a normal behaviour or should the firewall act more cleverly ? 
    This is Normal, otherwise the FW would not detect IPSpoofings. You MUST physicali separate the Networks.

    greetings
    eldorado
  • 0 in reply to eldorado
    Us a seperate hub for the DMZ. You LAN and DMZ can not shre the same hub
  • 0 in reply to lanman
    DMZ should be on a different hub for better protection if it is using a unique NIC.  An alternative is to put the DMZ net on ASL as "Additional IP Address" on the internal NIC and only use two NICs.  Best with 3 NICs but either way is more correct.