Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5

From: Maxim Konovalov (maxim_at_macomnet.ru)
Date: 12/04/04

  • Next message: Andre Oppermann: "Re: New Networking Project..."
    Date: Sun, 5 Dec 2004 00:53:52 +0300 (MSK)
    To: Andre Oppermann <andre@freebsd.org>
    
    

    On Sat, 4 Dec 2004, 21:37+0100, Andre Oppermann wrote:

    [...]
    > > Investigating pre-PFIL_HOOKS ipfw I have not found any analog of
    > > this check. These checks do break some useful functionality:
    > >
    > > 1) policy routing of hosts from connected networks
    > > 2) policy routing of locally originated traffic
    > >
    > > The second one is used very widely. When you have lines to two
    > > ISPs and run natd for both of them, you policy route nated packets
    > > to them.
    >
    > I know. On the other hand having these checks avoids breaking responses
    > from the host doing the policy routing towards hosts on connected networks.
    >
    > In my case I had a problem where the MTU of the policy-routing target
    > interface was lower than 1500 but the ICMP fragmentation needed packets
    > never made it back to the real host; they were forwarded to the policy
    > destination.
    >
    > This is how I came to this check. It is more correct but indeed breaks
    > forwarding packets that were targeted at an IP address configured on a
    > local interface. This is an unintended side effect but I haven't found
    > a nice solution to work around that. I'm not entirely sure what the
    > best way is to handle this and it's also the reason why I haven't changed
    > it so far.
    >
    > If you have suggestions I'm all ears. But think through all cases at least
    > twice, there are some nice traps. Fixing one end without breaking another
    > one is hard.

    IMHO restoring the historic behaviour (even broken in some respects)
    is the best thing we can do at the moment.

    > > P.S. kern/73129, kern/73910, kern/71910

    -- 
    Maxim Konovalov
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    

  • Next message: Andre Oppermann: "Re: New Networking Project..."

    Relevant Pages

    • Re: Do I Have A Firewalled LAN Run By ISP In Between?
      ... from that host while at host ... running a layer within a layer, with a complex network address translation ... application called "Internet Connection Sharing". ... what those packets are for, ...
      (comp.security.firewalls)
    • Re: IP over RS232 serial port under QNX6 (devn-fd.so)
      ... Now i can 'ping' and receive correct answers from the remote host. ... Now i want to setup the TCP/IP stack on top of the serial port. ... When i 'ping' to the destination endpoint 10.0.0.185 from the source ... These packets were correct ARP-Broadcasts ...
      (comp.os.qnx)
    • Re: Duplicate Echo Replies with Channel Bonding
      ... In this mode both interfaces receive packets, ... >When both eth0 and eth1 are up and I ping from Host C to Host A I get ... >The destination network 192.168.120.0/24 exists on both Router A and ... Switch B does not have the MAC address in its MAC address table ...
      (RedHat)
    • Re: Ip spoof from 0.0.0.0
      ... - A passive spoofed portscan with the attacker on the local ... segment watching the response packets go out to the default ... If a host responds to the syn packet sourced from 0.0.0.0 with an ack, ... it goes to the router either with the destination IP address rewritten ...
      (Incidents)
    • Re: Yet another thread on the legality of port scanning
      ... Which portthe packets are sent to is ... If I do a "nice", normal portscan on a host - via TCP, UDP or ICMP I am ... This sort of behavior is ... If I try to flood your host with abnormally LARGE ICMP packets endlessly ...
      (Security-Basics)