On 2007/03/15 12:50, Sebastian Reitenbach wrote: > I just found a workaround to my problem
that's good, I was thinking of reading your original message, but 100+ chars in a line results in nasty line breaks, making things really difficult to read - wrapping at 72 will get you a wider audience. > > Hi list, > > > > 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"
