ipfilter/ipnat 3.4.35 and udp-traceroute problem

From: Pawel Malachowski (pawmal-posting_at_freebsd.lublin.pl)
Date: 08/06/04

  • Next message: Alex Hoff: "Panic in Freebsd 4.7 (m_copydata/tcp_output)" 
    Date: Fri, 6 Aug 2004 00:54:08 +0200
To: freebsd-net@freebsd.org

    Hello,

    Can anobody here confirm that newest 3.4.35 IPFilter in RELENG_4 works with
    no problems when IPNATing traceroute UDP (+ICMP response) packets?

    I can see weird behavior of this command:
            traceroute -s privateIP -P UDP dst
    Outgoing UDP packets are translated, ICMP time-exceded message comes back,
    but traceroute shows '* * *'. ;)

    Commands:
            traceroute -s privateIP -P ICMP dst
    and
            traceroute -s privateIP -P TCP dst
    are working OK.

    UDP protocol is _not_ filtered.
    Also `traceroute -s publicIP -P UDP dst' works just fine. State table was
    flushed and has low number of mappings:
    mapped in 167718594 out 162841788
    added 4480473 expired 4466531
    no memory 0 bad nat 375052 <- hm
    inuse 2259 <=
    rules 38
    wilds 0

    Mapping rules (for this uplink and this privateIP) are quite common:
    map rl0 privateIP/20 -> publicIP/32 proxy port ftp ftp/tcp
    map rl0 privateIP/20 -> publicIP/32 portmap tcp/udp auto
    map rl0 privateIP/20 -> publicIP/32
    (/20 is big, but network is smaller, don't be scared).
    This ruleset was used for months with no problems. Kernel is almost GENERIC.

    Another interesting thing:
    % ipf -V
    ipf: IP Filter: v3.4.31 (336) <=
    Kernel: IP Filter: v3.4.35
    [...]
    % grep -i ver /usr/src/contrib/ipfilter/ipl.h
    #define IPL_VERSION "IP Filter: v3.4.31"

    Newer ipl.h sits happily in vendor branch. 

    -- 
Paweł Małachowski
_______________________________________________
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: Alex Hoff: "Panic in Freebsd 4.7 (m_copydata/tcp_output)"

    Relevant Pages

    • Re: UPD better than TCP in streaming video/audio ?
      ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
      (microsoft.public.win32.programmer.networks)
    • Re: NTP and Firewall help needed.
      ... >>port 123 for udp and tcp. ... The action here is applied for packets that fall off ... > - ACCEPT any and all traffic coming from the localhost interface ...
      (comp.os.linux.setup)
    • Re: Possible bug in .Net 2.0 udp sockets?
      ... You won't miss any UDP packets with a buffer that large! ... R> I called BeginReceiveFrom() several times on purpose, ... If you don't do that, indeed, UDP stack can drop packets. ... it stores it in the queue. ...
      (microsoft.public.dotnet.framework)
    • Re: UDP vs TCP
      ... I understand that UDP doesn't guarantee proper delivery of the message, that's why we have to add the CRC to the message to check if the message received is correct. ... TCP for instance will break up a large packet into smaller ... > into the packets and then the receiving app would have to read ...
      (microsoft.public.vb.enterprise)
    • Re: Update: UDP 770 Potential Worm
      ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
      (Incidents)