Date: Sat, 20 May 2000 09:18:29 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Gert-Jan Vons <vons@iname.com> Cc: ipfilter@coombs.anu.edu.au, freebsd-stable@freebsd.org Subject: Re: FTP proxy without translation no longer working? Message-ID: <200005201619.e4KGJEL03648@cwsys.cwsent.com> In-Reply-To: Your message of "Fri, 19 May 2000 09:37:28 %2B0200." <4.3.1.2.20000519092049.00b809e0@mail.vons.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Added freebsd-stable@freebsd.org to the cc list, as the solution may
be found there as well as on the IP Filter mailing list.
In message <4.3.1.2.20000519092049.00b809e0@mail.vons.local>, Gert-Jan
Vons wri
tes:
> At 02:43 19/05/2000 +1000, Darren Reed wrote:
>
> >In some email I received from Jefferson Ogata, sie wrote:
> >[...]
> > > Well, I'm having a really insane problem, and it's not making me happy.
> > > ...
> > > All IP Filter filtering and NAT features appear to work on both types,
> > > with the exception of FTP proxying. I haven't tested rdr.
> >
> >Both sets of rules are equivalent, with:
> >
> >map foo0 1.2.3.4/32 -> 5.6.7.8/32 proxy port ftp ftp/tcp
> >
> >(there is a bug with 0/32 on the RHS in 3.3.14)
>
> Can you tell me more about that bug? (do you have a work-around or a fix?)
>
> I am seeing problems with NAT and I do have a 0/32 on the RHS.
Actually it's the 0/0 part of the rule. For example:
map xl0 10.1.1.0/24 -> 0.0.0.0/32 proxy port ... works
map xl0 0.0.0.0/0 -> 0.0.0.0/32 proxy port ... doesn't
map xl0 10.1.1.0/24 -> 0.0.0.0/32 portmap tcp/udp 40000:60000 works
map xl0 0.0.0.0/0 -> 0.0.0.0/32 portmap tcp/udp 40000:60000 doesn't
>
> I started with FreeBSD 4.0-Release, ipfilter 3.3.13, and ppp from 11-4-2000.
>
> I updated in steps to 3.3.14 and then 3.4.2 (for those who mailed me about
> the -Werror, thanks for your help!), then installed the latest ppp of
> 11-5-2000, and was preparing to install a 4.0-Stable kernel.
>
> I haven't a clear description of the problem. Once I saw a SYN go out but
> nothing coming back, another time I didn't even see a SYN going out. I once
> got the impression that an "ipnat -CF -f /etc/ipnat.rules" made things
> work, but that may have been a coincidence.
>
> I don't have much time at the moment to investigate further (maybe in a
> week or two), so if this corresponds to a known problem...
I think that something in FreeBSD has changed. -stable as of April 22
had no problems with the commented out rules under 3.3.x and 3.4.3:
# map xl0 0.0.0.0/0 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map xl0 10.1.1.0/24 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map xl0 10.1.1.0/24 -> 0.0.0.0/32 portmap tcp/udp 40000:60000
map xl0 10.1.1.0/24 -> 0.0.0.0/32
map tun0 10.1.1.0/24 -> 0.0.0.0/32 portmap tcp/udp 40000:60000
map tun0 10.1.1.0/24 -> 0.0.0.0/32
map ppp0 10.1.1.0/24 -> 0.0.0.0/32 portmap tcp/udp 40000:60000
map ppp0 10.1.1.0/24 -> 0.0.0.0/32
map tun3 10.1.1.0/24 -> 0.0.0.0/32 portmap tcp/udp 40000:60000
map tun3 10.1.1.0/24 -> 0.0.0.0/32
# map tun3 0.0.0.0/0 -> 0.0.0.0/32 proxy port ekshell rcmd/tcp
# map tun3 0.0.0.0/0 -> 0.0.0.0/32 proxy port kshell rcmd/tcp
# map tun3 0.0.0.0/0 -> 0.0.0.0/32 proxy port shell rcmd/tcp
tun3 is a VPN (IPSec) session to my employer's site.
As of FreeBSD-stable from May 17 the 0/0 rules no longer work under
either IPF 3.3.15 or IPF 3.4.3. I think that the FreeBSD IP stack
was either broken or the FreeBSD IP stack is evolving in some way
that is incompatible with IP Filter (nobody's fault).
The symptoms using FreeBSD-4.0-STABLE as of May 17 are:
- No route to host messages or hung sessions, depending on the
protocol. Yet pings and traceroutes work.
- Adding the rule:
map tun3 0.0.0.0/0 -> 0.0.0.0/32 portmap tcp/udp 40000:60000
causes outbound telnet sessions to hang. This is not a proxy
problem but is related to NAT.
- NAT from systems on the LAN, through the gateway, e.g. the
uncommented NAT rules, work. In other words only NAT (proxy or
otherwise) sessions from the gateway itself fail. This seems to
indicate that FreeBSD's routing code has changed since a month
ago, as IPF injects the NATed packets back into the IP stack for
the routing tables to route (e.g. not Darren's fault).
I can see two paths to the solution:
1. FreeBSD IP stack is regressed or fixed to allow IP Filter to
inject packets into the stack (routing) as it did in April, or
2. Darren finds out what has changed, how it affects IP Filter
and adjusts IP Filter.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005201619.e4KGJEL03648>