Need best practice advice: carp and /30

[Catalin Miclaus]

-----Original Message-----
From: owner-freebsd-pf at freebsd.org [mailto:owner-freebsd-pf at freebsd.org]
On Behalf Of Tom Huppi
Sent: Tuesday, September 30, 2008 8:46 AM
To: freebsd-pf at freebsd.org
Subject: Need best practice advice: carp and /30


I am trying to build a pfsync implementation so that I can
work on various hardening and other experiments with minimal
downtime, and could use some advice.

I expect to be using the most current FreeBSD codebase with this
implementation.  Indeed, being able to do so is a driving force
behind my project.

My network layout looks like so:



                               -----------------
                          /--  | em0  PF-1  em1 | ---
        | ------------ | /     |      em2       |
 ISP -- | special vlan |       ----------------
        |  cisco 3560  |              |
        |------------- |\      ----------------          
                          \   |      em2       |
                            - | em0  PF-2  em1 | ----
                               ----------------



My ISP provides a single IP on a /30.  Say 70.187.255.246, and
that carries my class-C traffic which is on a different subnet
entirely.

A similar solution but with only one PF firewall (also acting as
a simple router) has been working well enough over the last 10
months, although I did have certain problems which I have yet to
get to the bottom of.  Possibly they have something to do with
the Cisco which I neglected to mention in my last query to this
list since I thought it unimportant at the time.

Anyway, my question relates to what are best-practices vis-a-vis
the network of the 'em0' interface.  Pretty clearly the carp0
interface is my ISP assigned one, but there is not room in the
/30 for other addresses.

My guess is that I should 'invent' a RFC1918 network for the two
em0 interfaces, but I certainly don't want this to cause wierd
problems in the VLAN (I don't anticipate doing any routing in
this VLAN, by the way.)

In my googleing I found some info about getting 'carpdev'
supported and the threads seem to have dried up over a year
ago, so I think that it is probably in and working these days(?)
Even if so, still remains unclear to me what is safe and
appropriate in my situation.

If anyone has experiance with a similar setup and hardware, I
would very much appreciate knowing of their experiances.  The
IOS revision on the Cisco is from about a year ago...don't have
it handy, but can get it if it is a factor.

(Also, thank you to all who had input on my last question to the
list.  I got some feedback from my ISP about it, but it only
adds to the mystery. I'll follow-up on that thread when I know
more.)

Thanks,

 - Tom


On external interface you need to configure at least the default route.
Moreover your ISP will have to configure same private range on his
equipments which I doubt he will agree.

The way I see it you have 2 solutions:

1. request for a /29 from your ISP
2. use enhanced image for 3560 (that will make it a layer 3 device) with
private range to your firewalls and public range on the ISP link











Best Regards
Catalin Miclaus
ISP-Data Ops.
Starcomms Ltd.



-- 
_______________________________________________
freebsd-pf at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"


DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any form of dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited if you are not the intended recipient of this e-mail. Please note that e-mails are susceptible to change. STARCOMMS PLC shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. STARCOMMS PLC does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. STARCOMMS PLC reserves the right to monitor all e-mail communications, whether related to the business of STARCOMMS or not, through its internal or external networks.