I followed the documentation trail to this page:
<http://ian.idallen.ca/dnat.txt>
which confirmed what I suspected, DNATd replies must flow back through
the DNAT'' (shorewall) host in order for the client to recognize to
which stream the reply belongs. NP.
I haven''t been able to find an example in the documentation where this
sort of SNAT is performed. Will the masq setup work for this case?
In my test, I''ve got all of the machines in the same ethernet domain,
on a switch. I''ve enabled arp_filter on both shorewall interfaces.
While this is only a test setup, I intend to run the shorewall
firewall in parallel with other services. It won''t be the gateway for
the firewall protected hosts because another device performs that
role.
My test setup looks like this.
<I> +-----------+
\______ | DSL Modem |
+-----------+
| X.25
|________________
| |
| X.26 | net=X.30
+-----------+ +------------+
| GW Router | | Shorewall |
+-----------+ +------------+
| 10.0.0.1 | loc=10.0.0.9
|_______________|
|
| 10.0.0.10
+------------+
| Web Server |
+------------+
The only difference between this logic map and the physical map is
that there is only one switch connecting these machines. The
shorewall host does have two, bonafide ethernet interfaces.
So, the following DNAT rule works, I can trace the packets and verify
that everything is correct.
# /etc/shorewall/rules
DNAT net loc:10.0.0.10 tcp 80
The trouble is that the reply is routed through GW because the default
gateway on the Web Server is 10.0.0.1. What I''d like to do is
something like this, I think:
iptables -t nat POSTROUTING -s 0/0 -d 10.0.0.10 -p tcp --dport 80 \
-j SNAT --to 10.0.0.9
I''ve toyed with
# /etc/shorewall/masq
eth0 eth1:!X 10.0.0.9 tcp 80
but the rules don''t look look right. I haven''t been able to
get the
source address portion correct.
Pointers will be appreciated.
Cheers.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Marc Singer wrote:> I followed the documentation trail to this page: > > <http://ian.idallen.ca/dnat.txt> > > which confirmed what I suspected, DNATd replies must flow back through > the DNAT'' (shorewall) host in order for the client to recognize to > which stream the reply belongs. NP. > > I haven''t been able to find an example in the documentation where this > sort of SNAT is performed. Will the masq setup work for this case? > > In my test, I''ve got all of the machines in the same ethernet domain, > on a switch. I''ve enabled arp_filter on both shorewall interfaces. > While this is only a test setup, I intend to run the shorewall > firewall in parallel with other services. It won''t be the gateway for > the firewall protected hosts because another device performs that > role. > > My test setup looks like this. > > > <I> +-----------+ > \______ | DSL Modem | > +-----------+ > | X.25 > |________________ > | | > | X.26 | net=X.30 > +-----------+ +------------+ > | GW Router | | Shorewall | > +-----------+ +------------+ > | 10.0.0.1 | loc=10.0.0.9 > |_______________| > | > | 10.0.0.10 > +------------+ > | Web Server | > +------------+ > > > The only difference between this logic map and the physical map is > that there is only one switch connecting these machines. The > shorewall host does have two, bonafide ethernet interfaces. > > So, the following DNAT rule works, I can trace the packets and verify > that everything is correct. > > # /etc/shorewall/rules > DNAT net loc:10.0.0.10 tcp 80 > > The trouble is that the reply is routed through GW because the default > gateway on the Web Server is 10.0.0.1. What I''d like to do is > something like this, I think: > > iptables -t nat POSTROUTING -s 0/0 -d 10.0.0.10 -p tcp --dport 80 \ > -j SNAT --to 10.0.0.9 > > I''ve toyed with > > # /etc/shorewall/masq > eth0 eth1:!X 10.0.0.9 tcp 80 > > but the rules don''t look look right. I haven''t been able to get the > source address portion correct. > > Pointers will be appreciated.I have a similar situation but with two firewalls servicing two CIDR blocks from two ISP''s. The cleanest solution I''ve found would be to add a subinterface to "Web Server" and create a routing table for that address which points to "Shorewall" as it''s default route. Something like: # ifconfig ethO:1 10.0.0.11 # ip route add 10.0.0.0/24 dev eth1 scope link table T1 # ip route add default via 10.0.0.9 table T1 # ip rule delete from 10.0.0.11 # ip rule add from 10.0.0.11 lookup T1 Then set the DNAT rule to DNAT net loc:10.0.0.11 tcp 80 - X.30 -- Stephen Carville <stephen@totalflood.com> Unix and Network Admin Nationwide Totalflood 6033 W. Century Blvd Los Angeles, CA 90045 310-342-3602 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Marc Singer wrote:> > but the rules don''t look look right. I haven''t been able to get the > source address portion correct. >What you are trying to do is impossible. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> Marc Singer wrote: > >>but the rules don''t look look right. I haven''t been able to get the >>source address portion correct. >> > > What you are trying to do is impossible. >In other words, you must arrange for the response packets to be *routed* back through the Shorewall box. -Tom PS -- what is the rationale behind this wacky setup? -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Thu, Sep 01, 2005 at 03:07:26PM -0700, Tom Eastep wrote:> Marc Singer wrote: > > > > > but the rules don''t look look right. I haven''t been able to get the > > source address portion correct. > > > > What you are trying to do is impossible.Impossible because iptables cannot do it? Or because shorewall cannot do it? I believe that iptables can handle this since it will match the destination address and port. Is there some other factor involved? ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
On Thu, Sep 01, 2005 at 03:16:01PM -0700, Tom Eastep wrote:> Tom Eastep wrote: > > Marc Singer wrote: > > > >>but the rules don''t look look right. I haven''t been able to get the > >>source address portion correct. > >> > > > > What you are trying to do is impossible. > > > > In other words, you must arrange for the response packets to be *routed* > back through the Shorewall box.Right. According to the author of the web page which I referenced, this can be done with SNAT such that the web server will always route response traffic back to the DNAT''ing device. His example is a little different because he wants machines on the protected betwork to depend on the DNAT box to gain route requests to the web server.> > -Tom > > PS -- what is the rationale behind this wacky setup?We want to be integrate the firewall into the network without interrupting existing traffic. It is only for port forwarding. Users gain access to the Big-I through the masqerading support in the gateway router, a Cisco, which cannot properly handle port forwarding due to FW bugs that Cisco admits are present and refuses to fix. Ugh. I''d like to replace all of these kinds of functions with shorewall, but I don''t have the luxury of doing a complete replacement at the moment. Cheers. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Marc Singer wrote:> On Thu, Sep 01, 2005 at 03:16:01PM -0700, Tom Eastep wrote: >>Tom Eastep wrote: >>>Marc Singer wrote: >>> >>>>but the rules don''t look look right. I haven''t been able to get the >>>>source address portion correct. >>>> >>>What you are trying to do is impossible. >>> >>In other words, you must arrange for the response packets to be *routed* >>back through the Shorewall box. > > Right. According to the author of the web page which I referenced, > this can be done with SNAT such that the web server will always route > response traffic back to the DNAT''ing device. His example is a little > different because he wants machines on the protected betwork to depend > on the DNAT box to gain route requests to the web server. >So in other words, you want all traffic forwarded by the Shorewall box to look like it originated on that box, thus loosing any accountability on the server of who the actual clients were? If that is what you are trying to do then on the Shorewall box, put this in the masq file: eth1 0.0.0.0/0 10.0.0.9 tcp 80 Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Thu, Sep 01, 2005 at 03:47:31PM -0700, Tom Eastep wrote:> Marc Singer wrote: > > On Thu, Sep 01, 2005 at 03:16:01PM -0700, Tom Eastep wrote: > >>Tom Eastep wrote: > >>>Marc Singer wrote: > >>> > >>>>but the rules don''t look look right. I haven''t been able to get the > >>>>source address portion correct. > >>>> > >>>What you are trying to do is impossible. > >>> > >>In other words, you must arrange for the response packets to be *routed* > >>back through the Shorewall box. > > > > Right. According to the author of the web page which I referenced, > > this can be done with SNAT such that the web server will always route > > response traffic back to the DNAT''ing device. His example is a little > > different because he wants machines on the protected betwork to depend > > on the DNAT box to gain route requests to the web server. > > > > So in other words, you want all traffic forwarded by the Shorewall box > to look like it originated on that box, thus loosing any accountability > on the server of who the actual clients were?Right. :-) Look. I know what it means to do this. We''re just interested in getting something working. If this works, and I expect it will, we can move to something better in small steps.> If that is what you are trying to do then on the Shorewall box, put this > in the masq file: > > eth1 0.0.0.0/0 10.0.0.9 tcp 80Ahah. I had tried 0/0 instead of 0.0.0.0/0. I''ll try it again. Cheers. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Marc Singer wrote:> On Thu, Sep 01, 2005 at 03:07:26PM -0700, Tom Eastep wrote: >>Marc Singer wrote: >> >>>but the rules don''t look look right. I haven''t been able to get the >>>source address portion correct. >>> >>What you are trying to do is impossible. > > Impossible because iptables cannot do it? Or because shorewall cannot > do it? > > I believe that iptables can handle this since it will match the > destination address and port. Is there some other factor involved?Marc, You''ve already replied to my follow-on to that post! Is the list scrambling the order of posts? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Thu, Sep 01, 2005 at 05:43:30PM -0700, Tom Eastep wrote:> Marc Singer wrote: > > On Thu, Sep 01, 2005 at 03:07:26PM -0700, Tom Eastep wrote: > >>Marc Singer wrote: > >> > >>>but the rules don''t look look right. I haven''t been able to get the > >>>source address portion correct. > >>> > >>What you are trying to do is impossible. > > > > Impossible because iptables cannot do it? Or because shorewall cannot > > do it? > > > > I believe that iptables can handle this since it will match the > > destination address and port. Is there some other factor involved? > > Marc, > > You''ve already replied to my follow-on to that post! Is the list > scrambling the order of posts?I''m not sure. This is a message much older than the last ones we exchanged. It looks like there is high latency in mail delivery. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Tom Eastep wrote:> Marc Singer wrote: >>On Thu, Sep 01, 2005 at 03:16:01PM -0700, Tom Eastep wrote: >>>Tom Eastep wrote: >>>>Marc Singer wrote: >>>> >>>>>but the rules don''t look look right. I haven''t been able to get the >>>>>source address portion correct. >>>>> >>>>What you are trying to do is impossible. >>>> >>>In other words, you must arrange for the response packets to be *routed* >>>back through the Shorewall box. >>Right. According to the author of the web page which I referenced, >>this can be done with SNAT such that the web server will always route >>response traffic back to the DNAT''ing device. His example is a little >>different because he wants machines on the protected betwork to depend >>on the DNAT box to gain route requests to the web server. >> > > So in other words, you want all traffic forwarded by the Shorewall box > to look like it originated on that box, thus loosing any accountability > on the server of who the actual clients were? > > If that is what you are trying to do then on the Shorewall box, put this > in the masq file: > > eth1 0.0.0.0/0 10.0.0.9 tcp 80 >The above assumes that your internal interface is eth1 -- I just realized that I used the internal interface name from Chip Burke''s related post. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Thu, Sep 01, 2005 at 06:08:36PM -0700, Tom Eastep wrote:> Tom Eastep wrote: > > Marc Singer wrote: > >>On Thu, Sep 01, 2005 at 03:16:01PM -0700, Tom Eastep wrote: > >>>Tom Eastep wrote: > >>>>Marc Singer wrote: > >>>> > >>>>>but the rules don''t look look right. I haven''t been able to get the > >>>>>source address portion correct. > >>>>> > >>>>What you are trying to do is impossible. > >>>> > >>>In other words, you must arrange for the response packets to be *routed* > >>>back through the Shorewall box. > >>Right. According to the author of the web page which I referenced, > >>this can be done with SNAT such that the web server will always route > >>response traffic back to the DNAT''ing device. His example is a little > >>different because he wants machines on the protected betwork to depend > >>on the DNAT box to gain route requests to the web server. > >> > > > > So in other words, you want all traffic forwarded by the Shorewall box > > to look like it originated on that box, thus loosing any accountability > > on the server of who the actual clients were? > > > > If that is what you are trying to do then on the Shorewall box, put this > > in the masq file: > > > > eth1 0.0.0.0/0 10.0.0.9 tcp 80 > > > > The above assumes that your internal interface is eth1 -- I just > realized that I used the internal interface name from Chip Burke''s > related post.No worries, I knew what you meant. It''s all good. It works as expected. Thanks a lot.> > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf