Re: Hiding NATs with PF

From: Simon Farnsworth (usenet_at_farnz.org.uk)
Date: 09/29/05 

Date: Thu, 29 Sep 2005 19:18:58 +0100

Max Bolingbroke wrote:
> Simon Farnsworth wrote:
>> You need a block rule to get PF to avoid it. Given a table <private> with
>> all RFC 1918 addresses in it:
>>
>> block quick on $ext_if from <private> to any
>
> Thats a great help. However, at the moment I am testing the NAT by
> having it nested within another NAT, so enabling this rule would block
> the external interface from sending/recieving any packets since it
> itself has an address in the 192.168.1.x range. I remedied this by
> using a rule like:
>
> block drop out quick on $ext_if from 192.168.2.0/24 to any
>
> Where the NATed network managed by OpenBSD has addresses in the range
> 192.168.2.x. This should be OK, right?
>
I'm the paranoid type, so I'd just change the table to not include your
external range.

table private const { 10/8, 172.16/12, 192.168/16, !192.168.1/24 } should do
it IIRC.

>> This stops your machine sourcing private addresses, and "all" you need to
>> do is make sure that the cables *never* get swapped; if your internal
>> interface is connected to the campus network, you run the risk of big
>> trouble.
>
> Mmm.. poisoning routing information would be the least of my worries
> given that I'd be handing out dhcp leases to all and sundry.
>
Which is of course another of their worries; if a DHCP lease gets handed to
another user, breaking their internet, the other user won't think it might
be your fault, they'll blame the helpdesk.

In addition, it's possible that some of their equipment (hopefully not
security critical) gets its own address via DHCP. If that equipment picks
up an address from your DHCP server, they'll have to send someone to hit
it, and that someone will want to hit you. Another good reason to be very
careful, and buy your IT staff some beer :) 

-- 
Simon Farnsworth