Does not work ...
After putting your lines in pf.conf, it just puts out a syntax error !?
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
>
> aso ...
>
>>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,
>>either.
>>
>
> Why that ? The next hop just sees that there is any IP that wants to go
> to whereever !?
>
>>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
[EMAIL PROTECTED] ~ # pfctl -f /etc/pf.conf
/etc/pf.conf:37: syntax error
pfctl: Syntax error in config file: pf rules not loaded
[EMAIL PROTECTED] ~ #
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" ?
>
>>A slightly more complex variant can be used to let internal network
>>servers talk via a split route to the internet.
>>
>>So, it's quite possible. That does not make it a good idea, though.
>>
>> Joachim
>
> ...olli
