First let me say that I have a working configuration. However I think
I have found a documentation issue. Although it is quite a bit more
likely that I am just doing something stupid. I have been a happy
shorewall user for several years now in other configurations.
I am running shorewall 3.0.7 on linux 2.6.12 on Debian stable with
shorewall installed from sarge-backports.
Following the documentation at http://www.shorewall.net/NAT.htm I
found it to match the situation I needed almost exactly. I want to
make a system configured with a private IP address to appear on
another network with an address on that network specifically for the
telnet port. (Everything is on a private network. I am not using
telnet on the Internet! It is really a remote dedicated device in
this configuration.)
15.6.88.87 host initiating the telnet connect
|
eth0 15.6.94.236
eth0:0 15.6.88.149
+-----+
|linux|
+-----+
eth1 10.1.0.1
|
10.1.0.2 host accepting the telnet
Following http://www.shorewall.net/NAT.htm I created the following:
/etc/shorewall/nat
#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
15.6.88.149 eth0 10.1.0.2 no yes
However the result of that configuration was unsuccessful. Regardless
of the setting of ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf
this never seemed to create an interface for 15.6.88.149. No ping.
Shouldn''t an IP alias have been created in the above configuration?
Eventually I created 15.6.88.149 manually labeled eth0:0 using Debian''s
/etc/network/interfaces and ifup. With a manually created interface
and the above configuration packets routed out eth1 but failed to have
their source addresses translated. Running tcpdump I found that the
packets leaving eth1 retained their original 15.6.88.87 source
address. When this showed up to the 10.1.0.2 host it discarded them
as an invalid packet for that network.
15.6.88.87 -> 15.6.88.149:23 into eth0
Became:
15.6.88.87 -> 10.1.0.2:23 out of eth1
Shouldn''t the source address have been translated to be from 10.1.0.1?
As per http://www.shorewall.net/Documentation.htm#Masq I added an SNAT
entry and this coupled with the nat rule above did route and translate
the source address.
/etc/shorewall/masq
#INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC
eth1 eth0 10.1.0.1
15.6.88.87 -> 15.6.88.149:23 into eth0
Became:
10.1.0.1 -> 10.1.0.2:23 out of eth1
Success! This configuration appears to work perfectly for me. I can
telnet to the 15.6.88.149 address and it routes and translates and a
connection is enabled. I can connect to the device on the private
address.
More background that may be relevant.
/etc/shorewall/policy
all all ACCEPT
But being a paranoid sort and worried that later someone would change
the default policy I have the following in the rules file. I know
this creates less efficient rules but performance is not an issue and
the traffic is low and the machine is fast. This is just everything
plus the kitchen sink.
/etc/shorewall/rules
ACCEPT all all icmp echo-request,time-exceeded
ACCEPT all all tcp ssh,domain,ntp,smtp,http,https,rsync,ftp,telnet
Unfortunately this box was needed and now people are using it and
things are working and so I can''t return it to the not quite working
configuration to capture the configuration. But I will have another
box to try this on soon and can collect information from it then.
Until then I have a configuration that is working. I am only hoping
to improve the documentation such that this would be easier for
someone else trying to do something similar.
Any ideas on what I was doing wrong? Or should the documentation for
one-to-one nat include creating the IP alias manually and adding a
masq entry too?
Along the way I also tried using DNAT in the rules file. The effect
was the same as the one-to-one nat configuration. Using the
documentation at http://www.shorewall.net/Documentation.htm#Rules I
was able to route packets but the source address was not translated.
This prevented a connection. The following effected the same behavior
as only having the nat file above without the masq file above.
/etc/shorewall/rules
DNAT net loc:10.1.0.2 tcp telnet 15.6.88.149
Thanks
Bob
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Thu, Jan 04, 2007 at 11:26:08PM -0700, Bob Proulx wrote:> > I am running shorewall 3.0.7 on linux 2.6.12 on Debian stable with > shorewall installed from sarge-backports. >Bob, Just FYI, but the version of shorewall in backports was updated to 3.2.6 a while ago. I''d update if I were you. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Bob Proulx wrote:> > 15.6.88.87 host initiating the telnet connect > | > eth0 15.6.94.236 > eth0:0 15.6.88.149 > +-----+ > |linux| > +-----+ > eth1 10.1.0.1 > | > 10.1.0.2 host accepting the telnet > > Following http://www.shorewall.net/NAT.htm I created the following: > > /etc/shorewall/nat > #EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL > 15.6.88.149 eth0 10.1.0.2 no yes > > However the result of that configuration was unsuccessful. Regardless > of the setting of ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf > this never seemed to create an interface for 15.6.88.149. No ping.Shorewall will never create an interface.> > Shouldn''t an IP alias have been created in the above configuration?No. But address 15.6.88.149 should have been added to the IPv4 configuration for eth0.> > Eventually I created 15.6.88.149 manually labeled eth0:0 using Debian''s > /etc/network/interfaces and ifup. With a manually created interface > and the above configuration packets routed out eth1 but failed to have > their source addresses translated. Running tcpdump I found that the > packets leaving eth1 retained their original 15.6.88.87 source > address. When this showed up to the 10.1.0.2 host it discarded them > as an invalid packet for that network.Why?> > 15.6.88.87 -> 15.6.88.149:23 into eth0 > Became: > 15.6.88.87 -> 10.1.0.2:23 out of eth1 > > Shouldn''t the source address have been translated to be from 10.1.0.1?No.> > As per http://www.shorewall.net/Documentation.htm#Masq I added an SNAT > entry and this coupled with the nat rule above did route and translate > the source address. > > /etc/shorewall/masq > #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC > eth1 eth0 10.1.0.1 > > 15.6.88.87 -> 15.6.88.149:23 into eth0 > Became: > 10.1.0.1 -> 10.1.0.2:23 out of eth1 > > Success! This configuration appears to work perfectly for me. I can > telnet to the 15.6.88.149 address and it routes and translates and a > connection is enabled. I can connect to the device on the private > address.> But I will have another > box to try this on soon and can collect information from it then. > Until then I have a configuration that is working. I am only hoping > to improve the documentation such that this would be easier for > someone else trying to do something similar.Ok. I would like to understand why the address apparently didn''t get added.> > Any ideas on what I was doing wrong? Or should the documentation for > one-to-one nat include creating the IP alias manually and adding a > masq entry too?Again, I don''t understand what the masq entry is necessary unless 10.1.0.2 doesn''t have a default gateway defined. As to creating the alias, the NAT documentation already includes this: Note Shorewall will automatically add the external address to the specified interface unless you specify ADD_IP_ALIASES=“no” (or “No”) in /etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or if you set it to “Yes” or “yes” then you must NOT configure your own alias(es). I have no idea why an address was not created for you with ADD_IP_ALIASES=Yes -- I would have to see a trace of "shorewall start" in order to understand what went wrong. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Roberto C. Sanchez wrote:> Bob Proulx wrote: > > I am running shorewall 3.0.7 on linux 2.6.12 on Debian stable with > > shorewall installed from sarge-backports. > > Just FYI, but the version of shorewall in backports was updated to 3.2.6 > a while ago. I''d update if I were you.But I just updated it from backports two days ago! When I look today the newest shorewall available on backports is 3.0.7-1~bpo.1. I do not see anything newer there. My intention was to have the newest available version. I found that part of the problem. I was using a mirror of backports and the mirror that I was using was stale. When I change to backports directly I see the newer versions there. I will send a note to the owner of the mirror and see that it gets updated. Thanks Bob ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> Bob Proulx wrote: > > /etc/shorewall/nat > > #EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL > > 15.6.88.149 eth0 10.1.0.2 no yes > > > > However the result of that configuration was unsuccessful. Regardless > > of the setting of ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf > > this never seemed to create an interface for 15.6.88.149. No ping. > > Shorewall will never create an interface.I am probably using the language poorly when I say interface. Sorry. (I know there is some distinction between interfaces and aliases and labels but I am not clued into the details.) I mean that I could never ping 15.6.88.149 nor find any response from it and so to me it did not appear to exist in any way. It it did not show up when looking with ifconfig such as I would normally expect to see. I see now that ''ip addr show'' displays this in a different way. But I have not previously known about ''ip addr show''. It is new and I am old.> > Shouldn''t an IP alias have been created in the above configuration? > > No. But address 15.6.88.149 should have been added to the IPv4 configuration > for eth0.Not knowing about ''ip addr show'' I don''t know what it would have said. I will have another setup to try this on shortly. I will collect that information there.> > Eventually I created 15.6.88.149 manually labeled eth0:0 using Debian''s > > /etc/network/interfaces and ifup. With a manually created interface > > and the above configuration packets routed out eth1 but failed to have > > their source addresses translated. Running tcpdump I found that the > > packets leaving eth1 retained their original 15.6.88.87 source > > address. When this showed up to the 10.1.0.2 host it discarded them > > as an invalid packet for that network. > > Why?I don''t know. It fails to respond to any those packets. But it does respond to packets on its own network. I assume because the network attached to it was 10.* and it had no way of accessing anything else. It would need a default route in order to talk off of the 10.* network. To the best of my knowledge that device does not have a default route. It is basically a toaster oven but with less brains. The translation did not behave as *I* expected and so I proceeded with my bias as to the problem.> > 15.6.88.87 -> 15.6.88.149:23 into eth0 > > Became: > > 15.6.88.87 -> 10.1.0.2:23 out of eth1 > > > > Shouldn''t the source address have been translated to be from 10.1.0.1? > > No.Huh? Why not? I think this is the root of my misunderstanding of how I should have approached this problem. Knowing the details here I think will clear everything up for me. When the destination address is translated I also expect that the source address would get translated too so that the remote device will be able to route a packet back to the sender. If not then how would the device with the hidden address ever be able to send a response back? As an analogy, a typical one-to-many NAT configuration such as would be used for a private network behind a firewall. (e.g. Internet <-> fw <-> 192.168.0.*.) When a host on the private network sends a packet out to the Internet and NAT is done there the source address 192.168.0.101 is translated to the address of the firewall/gateway router. If it were not translated then the Internet host would get 192.168.0.101 as the source address would not be able to respond. Why isn''t the one-to-one NAT case just the same as this case in terms of translating the source address? I think that question is the key point to my confusion. The model from my perspective is that this is just getting turned around and used in the reverse direction for the one-to-one NAT case. In any case seeing this like this now it makes sense to me that I would need to enter a ''masq'' file configuration to configure source address translation too. It makes sense that they are independent controls. I was just not expecting that from reading the documentation in the one-to-one nat area. I did not see any hints there that it might also be needed. I realize that you are saying that this should not be needed and obviously then would not be documented that way. But I don''t see how this would work without it and so I am still working to understand the disconnection between those two things. Thanks Bob ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Bob Proulx wrote:> It it did not show up when > looking with ifconfig such as I would normally expect to see. I see > now that ''ip addr show'' displays this in a different way. But I have > not previously known about ''ip addr show''. It is new and I am old.You might wish to read http://www1.shorewall.net/Shorewall_and_Aliased_Interfaces.html. It talks about these issues in some detail.> >>> Shouldn''t an IP alias have been created in the above configuration? >> No. But address 15.6.88.149 should have been added to the IPv4 configuration >> for eth0. > > Not knowing about ''ip addr show'' I don''t know what it would have > said. I will have another setup to try this on shortly. I will > collect that information there.Here''s an example: 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000 link/ether 00:02:e3:08:48:4c brd ff:ff:ff:ff:ff:ff inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0 inet 206.124.146.177/24 scope global secondary eth0 inet 206.124.146.178/24 scope global secondary eth0 inet 206.124.146.179/24 scope global secondary eth0 inet 206.124.146.180/24 scope global secondary eth0 inet6 fe80::202:e3ff:fe08:484c/64 scope link valid_lft forever preferred_lft forever Contrast that with what ifconfig shows: eth0 Link encap:Ethernet HWaddr 00:02:E3:08:48:4C inet addr:206.124.146.176 Bcast:206.124.146.255 Mask:255.255.255.0 inet6 addr: fe80::202:e3ff:fe08:484c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:24280 errors:0 dropped:0 overruns:0 frame:0 TX packets:43711 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:10126593 (9.6 MiB) TX bytes:9053058 (8.6 MiB) Interrupt:185 Base address:0x1000>>> >>> Shouldn''t the source address have been translated to be from 10.1.0.1? >> No. > > Huh? Why not?Because one-to-one NAT is not designed to handle only stupid toaster-ovens. The rewriting of the source address in a packet (SNAT) is *always* a work-around for some sort of inadequate routing and Shorewall doesn''t assume that the whole world has broken routing.> > I think this is the root of my misunderstanding of how I should have > approached this problem. Knowing the details here I think will clear > everything up for me. > > When the destination address is translated I also expect that the > source address would get translated too so that the remote device will > be able to route a packet back to the sender. If not then how would > the device with the hidden address ever be able to send a response > back?It sends responses just as it does requests -- based on its routing table. In your case, the routing table on your toaster-oven is incomplete so you have to implement an SNAT hack to work around that incompleteness.> > As an analogy, a typical one-to-many NAT configuration such as would > be used for a private network behind a firewall. (e.g. Internet <-> > fw <-> 192.168.0.*.) When a host on the private network sends a > packet out to the Internet and NAT is done there the source address > 192.168.0.101 is translated to the address of the firewall/gateway > router. If it were not translated then the Internet host would get > 192.168.0.101 as the source address would not be able to respond. Why > isn''t the one-to-one NAT case just the same as this case in terms of > translating the source address?It is -- but in the other direction. If your toaster-oven did have a default route and it sent a request addressed to 206.124.146.177, the source address would be rewritten to 15.6.88.149 so that 206.124.146.177 could respond.> I think that question is the key > point to my confusion. The model from my perspective is that this is > just getting turned around and used in the reverse direction for the > one-to-one NAT case.one-to-one NAT is just like a combination of: a) An entry in /etc/shorewall/masq for traffic in one direction. b) A DNAT- rule for traffic in the other direction. So you could rewrite your nat entry as: /etc/shorewall/masq: eth0 10.1.0.2 15.6.88.149 /etc/shorewall/rules: DNAT- net loc:10.1.0.2 - - - 15.6.88.149> > In any case seeing this like this now it makes sense to me that I > would need to enter a ''masq'' file configuration to configure source > address translation too. It makes sense that they are independent > controls. I was just not expecting that from reading the > documentation in the one-to-one nat area.Again, what you are doing is changing *both* the source and destination IP address for incoming traffic. That is not simple one-to-one NAT. HTH, -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV