-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Shorewall-3.0.3
RH9 (+legacy updates)
eth0: loc: 192.168.1.0/24
eth0:0: loc: 192.168.20.0/24
eth1:: 69.70.32.8/29
I''m worked all day on an issue I found today and I just can''t
find a way
to fix my problem.
So, basically, for now, my network looks like this:
Internet
^
|
(69.70.32.8/29)
Firewall
192.168.1.1
^
|
LAN/Servers
(192.168.1.0/24)
So, servers are nated (DNAT) from my external static ips to my LAN, this
works fine.
I use a SNAT for my outgoing traffic to go out on the internet using
69.70.32.10. This works fine.
I need to masq my own LAN to my firewall to be able to use the DNAT of
my external IPs inside my LAN, this works fine for now, but this is my
problem.
I want to add a new subnet (in a virtual interface of my LAN on the
firewall), 192.168.20.0/24. Everything''s setup, I get a problem, when I
am connecting from 192.168.1.0/24 to 192.168.20.0/24 (of vice-versa), I
am masqueraded as the interface of this network of the firewall.
(ssh 192.168.20.3 from 192.168.1.109 is saw as coming from 192.168.20.1).
This causes problems and I just want this subnet to be routed internally
with nothing more.
I included my config files and my status (status.txt) in the mail, but
my masq contains this:
#INTERFACE SUBNET ADDRESS PROTO PORT(S)
IPSEC
eth1 eth0 69.70.32.10
eth0 eth0
(eth0 eth0) looks weird, but it''s the only way I found to be able to
talk to my nat from the eth1 network from the LAN.
If I remove this line, I get what I want, being routed normaly inside,
but I can''t talk to my dnat from my /29 on the internet.
I tried to put thing in and out from the hosts file, but it doesn''t
change anything.
SO now I am asking for your help! ;)
Thanks a lot!
- --
Cédric Charest
Administrateur de Systèmes / System Administrator
Terrascale Technologies Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFD6R/MudvjQGGRi3oRAvPvAKCzAAoMx3bLaXgihx7t9qAsJ3nhMQCgth/o
Coem5MDS5sDq8y2JAPhWRaM=XF3O
-----END PGP SIGNATURE-----
On Tuesday 07 February 2006 14:31, Cedric Charest wrote:> If I remove this line, I get what I want, being routed normaly inside, > but I can''t talk to my dnat from my /29 on the internet.I don''t understand what that means. And since I don''t understand what the problem is, I can''t offer you a solution. When you "can''t talk...": Where are you connecting from? (IP address). What are you trying to connect to? (IP address, protocol, port). How do you expect the connection will be forwarded? (To which IP address) What happens? (Timeout, connection refused, firewall bursts into flames,...) -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 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
On Wednesday 08 February 2006 07:25, Tom Eastep wrote:> On Tuesday 07 February 2006 14:31, Cedric Charest wrote: > > If I remove this line, I get what I want, being routed normaly inside, > > but I can''t talk to my dnat from my /29 on the internet. > > I don''t understand what that means. And since I don''t understand what the > problem is, I can''t offer you a solution. > > When you "can''t talk...": > > Where are you connecting from? (IP address). > What are you trying to connect to? (IP address, protocol, port). > How do you expect the connection will be forwarded? (To which IP address) > What happens? (Timeout, connection refused, firewall bursts into > flames,...) >Also -- the status.txt in the tarball that you sent is incomplete and omits all of the details about NAT and your IP configuration. I can''t analyze your problem without knowing those details. -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 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote: What I want is:>> Where are you connecting from? (IP address).- From 192.168.1.109 (192.168.1.0/24)>> What are you trying to connect to? (IP address, protocol, port).To 192.168.20.0/24 (anything)>> How do you expect the connection will be forwarded? (To which IP address)I want to be able to connect normally, in a routed network: (ie: that the destination, 192.168.20.3 sees me as 192.168.1.109).>> What happens? (Timeout, connection refused, firewall bursts into >> flames,...)Connection ok, but I am masqueraded as 192.168.20.1 (the firewall IP in this subnet) when I am connected to the 192.168.20.0/24 network from the 192.168.1.0/24 network, which are both in the local network. What I have now:>> Where are you connecting from? (IP address).- From 192.168.1.109 (192.168.1.0/24)>> What are you trying to connect to? (IP address, protocol, port).To, let''s say, 69.70.32.13 (69.70.32.8/29) port 80 tcp>> How do you expect the connection will be forwarded? (To which IP address)It is forwarded to 192.168.1.11:80 tcp>> What happens? (Timeout, connection refused, firewall bursts into >> flames,...)This works fine. But if I want to fix my problem above, the only working thing I found was to remove, in the file *masq*, the line: #INTERFACE SUBNET ADDRESS PROTO PORT(S) - --> eth0 eth0 But if I remove this line, forwarding from 192.168.1.109 to 69.70.32.13:80 tcp --> (dnat to) 192.168.1.11:80 tcp does not work anymore. It gives me a connection refused.> Also -- the status.txt in the tarball that you sent is incomplete and omits > all of the details about NAT and your IP configuration. I can''t analyze your > problem without knowing those details.Yeah sorry, yesterday the shorewall dump stalled for 2 minutes without doing anything, I thought it was over. I put the new files in attachment. Thanks, - -Cedric Charest -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD6hpyudvjQGGRi3oRAuJeAKDYVPSynYQ+0ApN7lkYz6af7ZNGnwCgjwDN F3KkF4EBbh7udH2oevCmrmU=HT2U -----END PGP SIGNATURE-----
On Wednesday 08 February 2006 08:21, Cedric Charest wrote:> >> Where are you connecting from? (IP address). > > From 192.168.1.109 (192.168.1.0/24) > > >> What are you trying to connect to? (IP address, protocol, port). > > To, let''s say, 69.70.32.13 (69.70.32.8/29) port 80 tcp > > >> How do you expect the connection will be forwarded? (To which IP > >> address) > > It is forwarded to 192.168.1.11:80 tcp > > >> What happens? (Timeout, connection refused, firewall bursts into > >> flames,...) > > This works fine. But if I want to fix my problem above, the only working > thing I found was to remove, in the file *masq*, the line: > #INTERFACE SUBNET ADDRESS PROTO PORT(S) > --> eth0 eth0 > But if I remove this line, forwarding from 192.168.1.109 to > 69.70.32.13:80 tcp --> (dnat to) 192.168.1.11:80 tcp does not work > anymore. It gives me a connection refused. > > > Also -- the status.txt in the tarball that you sent is incomplete and > > omits all of the details about NAT and your IP configuration. I can''t > > analyze your problem without knowing those details. > > Yeah sorry, yesterday the shorewall dump stalled for 2 minutes without > doing anything, I thought it was over. I put the new files in attachment.Ok -- this sounds like you are dealing essentially with Shorewall FAQ 2. As in that FAQ, the correct way to solve the problem is to implement split DNS. That way, your local systems will connect to the servers using their local IP addresses and you don''t have to deal with any of this local DNAT/SNAT nonsense. If you continue to do the silly thing (local DNAT/SNAT), you need to replace the "eth0 eth0" rule with a more focused set of rules that only SNAT the traffic that is DNATed. For example: eth0:192.168.1.11 eth0:192.168.1.0/24 tcp 80 - 192.168.1.1 That will allow the redirecton of your web server traffic to work without affecting loc->loc SSH traffic. It''s still an ugly hack... -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 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
On Wednesday 08 February 2006 09:06, Tom Eastep wrote:> > If you continue to do the silly thing (local DNAT/SNAT), you need to > replace the "eth0 eth0" rule with a more focused set of rules that only > SNAT the traffic that is DNATed. For example: > > eth0:192.168.1.11 eth0:192.168.1.0/24 tcp 80 - 192.168.1.1Sorry -- the above syntax is wrong. I mixed /etc/shorewall/rules and /etc/shorewall/masq syntax. Should be (/etc/shorewall/masq): eth0:192.168.1.11 eth0:192.168.1.0/24 192.168.1.1 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 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
On Wednesday 08 February 2006 09:47, Tom Eastep wrote:> On Wednesday 08 February 2006 09:06, Tom Eastep wrote: > > If you continue to do the silly thing (local DNAT/SNAT), you need to > > replace the "eth0 eth0" rule with a more focused set of rules that only > > SNAT the traffic that is DNATed. For example: > > > > eth0:192.168.1.11 eth0:192.168.1.0/24 tcp 80 - 192.168.1.1 > > Sorry -- the above syntax is wrong. I mixed /etc/shorewall/rules > and /etc/shorewall/masq syntax. > > Should be (/etc/shorewall/masq): > > eth0:192.168.1.11 eth0:192.168.1.0/24 192.168.1.1 tcp 80Groan -- isn''t my day. One last try: eth0:192.168.1.11 192.168.1.0/24 192.168.1.1 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 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote:> On Wednesday 08 February 2006 09:47, Tom Eastep wrote: >>> If you continue to do the silly thing (local DNAT/SNAT), you need to >>> replace the "eth0 eth0" rule with a more focused set of rules that only >>> SNAT the traffic that is DNATed. For example: >>> >>> eth0:192.168.1.11 eth0:192.168.1.0/24 tcp 80 - 192.168.1.1 >> Sorry -- the above syntax is wrong. I mixed /etc/shorewall/rules >> and /etc/shorewall/masq syntax. >> >> Should be (/etc/shorewall/masq): >> >> eth0:192.168.1.11 eth0:192.168.1.0/24 192.168.1.1 tcp 80 > > Groan -- isn''t my day. > > One last try: > > eth0:192.168.1.11 192.168.1.0/24 192.168.1.1 tcp 80 > > -Tomhehe indeed! I agree, it''s an ugly way to do it, but I find this prettier than playing with different DNS zones! ;) Thank you Tom for the enlightenments! - -Cedric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD6jJHudvjQGGRi3oRAiWZAKCcgV8go/+KlnubWjjjuAvgkWeVJACgnka/ dnyKaWiad8mzIWA7SjZQ1Eg=C0yF -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642