Hi list,
again with wrapped lines. sorry for the first one...

I have a carped firewall cluster which is connected to the internet via a
cable interface, and one dsl interface, which is used as the default route.
The cable IP address is static, and the dsl IP address is dynamic. On the
static IP address the traffic is redirected into the DMZ. The traffic from
the Internal lan is sent out via the DSL interface, these are just the users
that are surfing. There I do not have a problem, this works well. On the
cable interface, I told my provider that the MAC address is the one of the
carp IP address. With the rules below, it is possible to communicate from 
the DMZ to the Internet via the Cable Interface, due to the route-to 
statement. The route-to ($cable_if $cable_gate) sends out my 
packets with the MAC address of the carp device, so this works well, as I
expect. But when I try to connect to the external $cable_mail_ip, with the
second reply-to rule, where I use ($cable_if $cable_gate) then the packets
are going into the firewall, to the DMZ host. The DMZ host is answering, and
the packets arrive again on the firewall, but then they disappear. I had a
tcpdump running on all my interfaces, but they did not showed up anywhere... 
When I use the commented out reply-to rule ($cable_dev $cable_gate), and do
not change anything else, then it is working as expected. I can telnet to
the mail ports of the mailer in the DMZ. The only drawback is, that then the
MAC address of the physical addresses of the cable_dev is used, but these
are filtered at my cable ISP. 

cable_dev="em0"
cable_if="carp0"

dmz_dev="em1"
dmz_if="carp1"

dsl_dev="vlan12"
dsl_if="carp13"

cable_mailer="10.10.10.10"
mail_ports="{25, 993}"

nat on $cable_dev from $dmz_net -> $cable_mail_ip
rdr on $cable_dev proto tcp to $cable_mail_ip port $mail_ports -> 
$cable_mailer

block in log all
pass out log all keep state


# allow communication from DMZ to Internet
pass in log on $dmz_dev route-to ($cable_if $cable_gate) proto udp from 
$dmz_net
to any port 
{ 53, 123 } keep state
pass in log on $dmz_dev route-to ($cable_if $cable_gate) proto tcp from 
$dmz_net
to any port 
{ 21, 25, 53, 80, 443 } modulate state flags S/SA

#pass in log on $cable_dev reply-to ($cable_dev $cable_gate) proto tcp \
  from any to $cable_mail port $ogo_mail_ports modulate state flags S/SA
pass in log on $cable_dev reply-to ($cable_if $cable_gate) proto tcp from \
  any to $cable_mail port $ogo_mail_ports modulate state flags S/SA


I am running OpenBSD 4.0, release. Sorry for cross posting, I am not that
sure whether it might be a pf problem, or sth. openbsd related, therefore to
the two mailing lists. For me this looks like a bug how reply-to statements 
are handled, but maybe I did sth. wrong?

My workaround is to fake the lladdr of the physical interface to be the same 
as the one of the carp interface and use the reply-to rule ($cable_dev 
$cable_gate)

kind regards
Sebastian

Reply via email to