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 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
