Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 7755 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

IP Spoofing problem

iealtd webmaster
Hi,

This is probably something really simply, but I cannot sort out why.

I have an internal network on x.y.40.* and a DMZ network on x.y.80.* (x and y are the same on both networks). The two networks have no connection between them. I have recently placed a program on the DMZ that emails reports. I have configured the SMTP server to listen on the DMZ network. However, when a report is emailed, I get the following messages in the logs

May 11 08:52:38 (none) kernel: IP-SPOOFING Drop: IN=eth2 OUT= MAC=00:05:5d:a1[:D]3:46:00:02:b3:25:a5:9f:08:00 SRC=x.y.80.102 DST=x.y.80.254 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=37717 DF PROTO=TCP SPT=4761 DPT=25 WINDOW=16384 RES=0x00 SYN URGP=0

I am get the same kind of messages on port 137 as well, but that's Windows for you  [:)]

Anybody got any ideas why these packets are being dropped ?

Thanks in advance

 ianb@iealtd.co.uk   


This thread was automatically locked due to age.
  • 0
    Okay, I admit it.

    I'm a wally.

    I didn't realise that some %$£&^% had changed the subnet mask for the x.y.40.* interface to 255.255.0.0

    All makes sense now. And it all works when I put it back to 255.255.255.0, which is as it should be.

    Sorry for taking up server space  [:)]  
  • 0 in reply to iealtd webmaster
    hey, that seems to come close to my problem...

    internal like x.y.80.0/255.255.255.0
    external like x.y.40.0/255.255.0.0

    everything is reached fine on asl, but from internal to external i get the same error "ip-spoofing" in kernel log file.
    Bad thing on it is, that i loose web-admin connection of course, so it's not easy to read this log file.... ;-(

    but i NEED it that way, to access Internet from internal.
    i tried to add static routes, blamed proxy-arp and so on,
    but now it looks like ip-spoofing-detection problem ...

    can anybody help me on this????

    kind regards from germany

    christian   
  • 0 in reply to Chris_W
    The problem is that the IP range covered by x.y.80.0/255.255.255.0 is also covered by x.y.40.0/255.255.0.0 (or more accurately x.y.0.0/255.255.0.0).

    If you are forced to have x.y.0.0 on the external interface, then you are going to have to change the internal subnet to something else.

     
  • 0 in reply to norwich
    but it should be possible to switch off this feature!

    there are files
    /proc/sys/net/ipv4/conf/eth_x_/rp_filter
    where eth_x_ actually is eth0 / eth1 / eth
    2.
    these contain 0 or 1 (wether spoofing protection is on or not)

    My box has these set to : 
     1 for the external/internal interfaces
     0 for the DMZ interface (192.168.1.250 / 24)

    i don't know where these are initialized, so i could disable this fieature.
    i tried to edit the file by hand, but was not really locky on this.
    Can anybody help me"

    kind regards
    Christian   
  • 0 in reply to Chris_W
    Hey Christian,

    Did you find a solution to an "IP SPOOFING" rules by any chance? I like Astaro very much, but sometimes it is very frustrating how unflexible it can be. It should be up to an admin to decide how to secure his/her own network... 

    I searched all over Astaro forums and did not see a dicent respond form Astaro Admins. 

    Astaro admins, if you read this post, can we please discuss this?

    Thanks.
     [:S]
    -Askar  
  • 0 in reply to askar
    did you guys get your spoofing filter rules in place?

    I have these rules in place:

    2  Any Any WAN_Broadcast__ Drop  edit del move 
    3  Any Any DMZ_Broadcast__ Drop  edit del move 
    4  Any Any LAN_Broadcast__ Drop  edit del move 
    5  { Private_Networks_-_RFC1918 } Any WAN_Network__ Drop  edit del move 


    Rule 5 should be what you need.  this should stop all RFC1918 addresses from entering the WAN Interface.


    let me know if you need more help...
      
  • 0 in reply to uncue75
    I don't believe you are talking about the same thing. Read the tread again. We are not trying to stop packets sourced or destined to private or multicasst IP space. 

      
  • 0 in reply to askar
    sorry... I guess I wasn't paying attention...