FW: [sclug] Firewalls

[lug at assursys.co.uk]

On Wed, 15 Jan 2003, Tom Dawes-Gamble wrote:

> lug at assursys.co.uk wrote:
> > On Wed, 15 Jan 2003, Tom Dawes-Gamble wrote:
> >>lug at assursys.co.uk wrote:
> >>>On Wed, 15 Jan 2003, Tom Dawes-Gamble wrote:
> >>>>lug at assursys.co.uk wrote:
> >>>>>On Wed, 15 Jan 2003, Tom Dawes-Gamble wrote:
> >>>>>>Yes,  but NAT sould only change the envelope part of the packet and not the
> >>>>>>contents.
> >>>>>
> >>>>>
> >>>>>That depends. It's impossible to get some protocols (non-PASV FTP being the
> >>>>>most notable) working without modifying the payload. Yes, this is prone to
> >>>>>error - consider what happens to the size of the packet if the client
> >>>>>address is 1.2.3.4 and the NATted address is 111.122.133.144. Now consider
> >>>>>what happens if the payload was already of size (MTU-40)...
> >>>>>
> >>>>
> >>>>That's not a nice exercise to leave to the reader.  :-)
> >>>>Though my guess is
> >>>>
> >>>>MTU - 40 = MTU - Envelope
> >>>>
> >>>>then in the envelope 1.2.3.4 would be 00000001 00000010 00000011 00000100
> >>>>         and 111.122.133.144 would be 01101111 01111010 10000101 10010000
> >>>>
> >>>>in that case the envelope does not change size.
> >>>
> >>>
> >>>It would be, apart from the fact that FTP uses ASCII when sending PORT
> >>>commands... suddenly your packet is 4x2=8 bytes longer than it was. But the
> >>>packet was already at maximum MTU size! Yow!
> >>>
> >>
> >>But surely the port "command" is not part of the envelope but is in body.
> > 
> > 
> > Sorry, missed that. But... in re-writing the ASCII PORT command in the
> > payload, tha payload has grown by 8 bytes, thus taking the total packet size
> > over the MTU size. The NAT device now needs to fragment the packet and
> > recalculate checksums without either side being made aware of what it's up
> > to.
> > 
> 
> I'm not that up to the mark on the good old seven layer model and all
> that jazz. Or exactly what layers are what in the TCP/IP stuff.  SO I
> find it difficult to explain.  IMVHO.  If ftp is transmitting IP addresses
> and port numbers in the data part thats a bit wrong.

Tell that to the designers of the FTP protocol! I can't really think what
their justification was to do it that way. ;-)

In mitigation, PASV-mode FTP pretty much makes things right.

> > Early-ish versions of a certain proprietary firewall product couldn't cope
> > when asked to do this.
> 
> As I said that's not a nice exercise to give the reader.  :-)

Actually, looking at the iptables source, I can't see any code to handle
this special case...

> Though I thought that changes in the MTU from place to place happend
> all the time.

That might be one way of handling it - send a ICMP dest unreachable back to
the client and force it to adjust its PMTU.

>  I have no idea what MTU I have set on the Network cards
> on my systems.  Nor do I know what MTU is used on the ISDN router I use
> for my home to work connection or on the Speedbox my ISP provides for my
> internet access.  Any difference in MTU should be delt by whatever layer
> worries about that.

It should be, but an awareness of MTU issues can help with all sorts of
problems. Only a few weeks back, BT suddendly decided to reduce the MTU of
some interface on a router in their core network. The end-result being that
I suddenly started getting fragmented packets back, which my firewalls
weren't expecting...

> Tom.

Alex.
-- 
Alex Butcher        Brainbench MVP for Internet Security: www.brainbench.com
Bristol, UK                        Need reliable and secure network systems?
PGP/GnuPG ID:0x271fd950                           <http://www.assursys.com/>