Re: Hiding NATs with PF

From: jpd (read_the_sig_at_do.not.spam.it.invalid)
Date: 09/29/05 

Date: 29 Sep 2005 20:33:35 GMT

Begin <mpnt03-pkt.ln1@rimmer.farnz.org.uk>
On 2005-09-29, Simon Farnsworth <usenet@farnz.org.uk> wrote:
>> 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.

I'd rather advocate a rule that *only* allows packets with a valid
public (and locally assigned) source IP to go out the external
interface. This after any NAT operations, of course. But since this is
the ultimate goal, it is a good idea to enforce it in spite of other
possible system faillures.

A good place to filter for RFC1918 (and LINK-LOCAL: 169.254.0.0/16,
and localhost, and so on) addresses is *incoming* on the external
interface, both source and destination. I'd also add a rule that
disallows multicast addresses as source address regardless of direction.
Normally I make a point of doing the right thing WRT returning ICMP
UNREACH packets (within reason, and as long as routable) but multicast
source addresses get dropped without exception.

Multicast addresses as destination are acceptable especially if you're on
a campus where multicast may be enabled and thus be experimented with.

>> 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.

True. This is another reason why ideally the router/firewall should do
nothing else. If you then add another box that does, oh, I don't know,
DCHP, NFS, SMB, DNS, and whatnot else, it should at least be well-contained
within your network courtesy of the router/firewall.

The only thing that you could add on the router-firewall is a (caching,
as a bonus/exception) proxy to scrub out any protocol level mentioning
of internal addresses. Think also SNMP including Received: headers,
IRC, and so on. Also: multicast service announcements from within your
network. This really needs attention if you're going to use multicast. 

-- 
  j p d (at) d s b (dot) t u d e l f t (dot) n l .

Relevant Pages

  • Re: Multicast on 21CN
    ... so that the ISPs would stand to save ... of video content distribution in the 21CN network. ... Distribution at this level is made possible by using multicast, ... The BBC carrot approach may help (the streams over multicast are ...
    (uk.telecom.broadband)
  • Re: Multicast on 21CN
    ... of video content distribution in the 21CN network. ... it says that multicast can be distributed from the different levels ... If BT do multicast in the DSLAM then the ISPs are getting something ...
    (uk.telecom.broadband)
  • Re: Multicast not working after switch
    ... verify that network team can see the multicast stream on the network ...
    (microsoft.public.windowsmedia.server)
  • Re: Help with IGMP
    ... By default it should forward multicast traffic to all port. ... good, it clog the network. ... It switch is has no VLAN or single VLAN and all ... the layer 2 protocol to allow switch interfaces to join multcast streams. ...
    (comp.dcom.sys.cisco)
  • Broadcast and multicast using VW Opentalk
    ... I'm no network protocol guru by any means, ... I'm not sure that multicast or broadcast can do ... or whether it would work on clients over the internet. ... I suppose the point is, the clients will be anywhere on the internet, ...
    (comp.lang.smalltalk)