On Fri, Mar 03, 2006 at 03:03:23PM +0100, oliver simon wrote:
> Hi again .. ;-)
>
> Joachim Schipper wrote:
> > On Fri, Mar 03, 2006 at 02:01:22PM +0100, oliver simon wrote:
> >>Hi Alex,
> >>
> >>Alexander Bochmann wrote:
> >>>Hi,
> >>>
> >>>...on Fri, Mar 03, 2006 at 01:08:43PM +0100, oliver simon wrote:
> >>>
> >>> > hme1 -> 10.50.0.10
> >>> > hme0 -> 217.5.23.69
> >>> > hme0_alias -> 217.5.23.70
> >>> > default-gw is 10.50.0.1
> >>> > If you want to connect to e.g. 193.44.25.2, the machine has to go there
> >>> > with one of it4s official IPs 217...
> >>>
> >>>Are you shure that's a sane setup? Why do you
> >>>want to reach the outside world through an interface
> >>>on a private segment when you have official addresses
> >>>on another interface? And why is there no address
> >>>translation elsewhere between your private segment
> >>>and wherever it connects to the Internet?
> >>It4s a server in a DMZ, so we have one "host"-ip (the private one), but
> >>the machine needs to be connected from the internet (apache) and put
> >>some requests through other .. "private-ip-ed" Servers/Firewalls to
> >>other apaches. Machine4s default gw is a private-ip-ed firewall, but
> >>otherwise we need to connect other servers in the internet. For being
> >>routed back to the machine from the target, the request to the "outer
> >>world" has to be done by an official ip.
> >
> > Not a very good setup, if I might say so. OpenBSD can do it, but I'd
> > strongly suggest placing the server in a DMZ (*not* on your internal
> > network) and using a single connection to internet from there.
>
> Internal Network is another IP-Range ... DMZ has official IPs for the
> services and its private ip-range for the hosts themself.
>
> DMZ: 10.50.0.0/24 + Official IPs for services
> Internal(!)Lan: 10.23.0.0/24
> DBNet (e.g.): 10.28.0.0/24
Okay, that makes a little more sense. Still, it's better to let the
gateway device(s) handle the weird networking stuff and let the servers
just chunk out data, at least conceptually, but this at least makes some
sense.
> > Anyway, use pf route-to and reply-to to override the routing table for
> > select flows. This is a much better idea than the split routing
> > mentioned below.
> >>> > How can we solve that problem ? I read a lot about pf and other things,
> >>> > but nothing I tried is working ...
> >>>
> >>>You can NAT the traffic going out through hme1, but you
> >>>will have a nice split routing situation, as the traffic
> >>>flowing back to you will probably come in through hme0.
> >>>Not that that's a problem, it just doesn't make any sense.
> >>That are my questions .. How can we solve that ? Currently, we are using
> >>linux (which shall be replaced through openbsd), and there is no problem
> >>to do that source-routing:
> >>
> >>/sbin/ip route add 194.78.111.123/32 via 10.50.0.1 src 217.5.130.99
> >
> > Source routing is evil, don't do it. No sane firewall should accept it,
>
> Why that ? The next hop just sees that there is any IP that wants to go
> to whereever !?
Well, it allows IP address spoofing. This is not too useful with TCP, as
the handshake cannot be completed, but rather neat where UDP or ICMP is
concerned, for example when (D)DoSing a machine.
> > The proper solution would not change any of the information posted
> > above, but add something like the following to pf.conf:
> >
> > out_if="hme1"
> > pass on $out_if from port { http https } reply-to $out_if
>
> Thats all ? If we want that not just for http/s, its just "from any" ?
Hmm, yes, but as you noted, you'll want to make that actually work. The
proper rule, according to pfctl -n, on my system, is:
pass out on $out_if reply-to $out_if:0 proto tcp from port { http https }
Sorry, I was a bit too quick the first time round.
Joachim
