Den 13-09-2014 17:11, Tom Eastep skrev:
> On 9/13/2014 5:20 AM, Paolo Nesti Poggi wrote:
>> Den 08-09-2014 10:33, Paolo Nesti Poggi skrev:
>>> Den 08-09-2014 01:24, Tom Eastep skrev:
>>>> On 9/5/2014 3:29 AM, Paolo Nesti Poggi wrote:
>>>>> Hi
>>>>> We use a shorewall 4.4.11.6, with a 3 NIC setup (net - dmz - localnet)
>>>>> that has been working flawlessly for years.
>>>>> Now we have changed broadband provider and with it we've got new IP
>>>>> addresses.
>>>>> I've reconfigured shorewall with the new addresses and since then we no
>>>>> longer have functioning DNAT for boxes that are forwarded from IP
>>>>> different from the main IP address.
>>>>>
>>>>> As far as I could see, for doing the provider change we only needed to
>>>>> edit the params (params for main IP and ekstra IPs)and  masq file (main
>>>>> IP), apart from of course /etc/network/interfaces and /etc/dhcp/dhcpd.conf
>>>>>
>>>>> Having done those changes everything works OK, even DNAT from the main
>>>>> IP to boxes on DMZ or localnet, whilst the DNAT rules for boxes
>>>>> forwarded to from other IPs in the address range are not working at all
>>>>> (ssh: connect to host 89.233.14.37 port 22: Connection timed out)
>>>>>
>>>>> I hope you can help me find a way to further troubleshoot this.
>>>>>
>>>>> I've re-read the section regarding the 3-interface setup:
>>>>> http://shorewall.net/three-interface.htm
>>>>> and the
>>>>> DNAT troubleshooting http://shorewall.net/FAQ.htm#faq1a and #faq1b
>>>>>
>>>>> The routes I'm troubleshooting all show 0 packets in the output of
>>>>> 'shorewall show nat', however the ISP ensures me that they are not
>>>>> dropping anything (this is a 200Mb/sec symmetric connection).
>>>>>
>>>>> The output of 'shorewal show nat' for one of the hosts in question is:
>>>>>       0     0 DNAT       tcp  --  *      *       0.0.0.0/0 89.233.14.37
>>>>>         multiport dports 22,80,443,3690,8000,5001,3306 to:192.168.37.37
>>>>>       0     0 DNAT       udp  --  *      *       0.0.0.0/0 89.233.14.37
>>>>>         multiport dports 5001,22,3306 to:192.168.37.37
>>>>>
>>>>> where doing 'ssh 89.233.14.37' from a  host outside of this network
>>>>> should connect me to my box on 192.168.37.37 in the local network.
>>>>> If I set up a Windows PC with static address 89.233.14.37 and connect it
>>>>> to the switch of my provider I can ping it from outside, but if I try
>>>>> and connect to my box on 192.168.37.37 I only get "Connection timed out"
>>>>>
>>>>> Do you have any idea of what might be going wrong and/or how I can move
>>>>> forward in troubleshooting this issue?
>>>>>
>>>> Have you confirmed with tcpdump that the tcp port22 are even reaching
>>>> the firewall and that they have the correct L2 destination address?
>>>>
>>>>
>>> The only thing I have from tcpdump reg. these addresses when I try and
>>> ssh to them are ARP messages like this:
>>>
>>> 14:29:55.386918 ARP, Request who-has 89.233.14.37 tell 89.233.14.33,
>>> length 46
>>>
>>> About the gateway (89.233.14.33), I was reading about
>>> http://shorewall.net/shorewall_setup_guide.htm#Options and I get now
>>> that probably the decisive difference between the old set up and the
>>> new one (apart from the single addresses) is that previously we had a
>>> non-routed setup, because the addresses were in two different
>>> segments, while we now have a whole subnet (89.233.14.32/28),
>>> therefore we need to change /etc/network/interfaces accordingly.
>>>
>>> If this is correct am I right in understanding that the section:
>>> "*Routed* - Traffic to any of your addresses will be routed through a
>>> single gateway address. This will generally only be done if your ISP
>>> has assigned you a complete subnet (/29 or larger). In this case, you
>>> will assign the gateway address as the IP address of your
>>> firewall/router's external interface."
>>>
>>> Means that '/etc/network/interfaces' should be:
>>>
>>>          address 89.233.14.33
>>>          network 89.233.14.32/28
>>>          broadcast 89.233.14.47
>>>          netmask 255.255.255.240
>>>          gateway 89.233.14.33
>>>
>>> and not
>>>
>>>          address 89.233.14.34
>>>          network 89.233.14.32/28
>>>          broadcast 89.233.14.47
>>>          netmask 255.255.255.240
>>>          gateway 89.233.14.33
>>>
>>> as we have now?
>> Hi again,
>> Hope to get som feed back about some more findings. I also hope not to
>> offende anybody reporting about some obviously wrong trials.
>> I'm trying at least to rule out options.
>>
>> 1. I have tried out configuring the IP address as I had understood the
>> section mentioned above ("routed" setup), hence with
>> /etc/network/interfaces like:
>>
>> iface eth0 inet static
>>          address 89.233.14.33
>>          network 89.233.14.32/28
>>          netmask 255.255.255.240
>>          broadcast 89.233.14.47
>>          gateway 89.233.14.33
>>
>>
>> Accordingly I also changed the masq file to have 89.233.14.33 as
>> external address.
>>
>> This did not work at all. No connection from local to internet not to
>> mention the other way around.
>> A tcpdump shows Wireshark complaining about;
>> "Expert Info (Warn/Sequence): Duplicate IP address configured
>> (89.233.14.33)"
>>
>> Which of course is exactly what I did, I gave our NIC an IP address that
>> our provider has already given to their device (the gateway).
>>
>> It could be interesting to know what/how I did misunderstand the text
>> "*Routed* - Traffic to any of your addresses will be routed ..." cited
>> above from the documentation.
>>
>> 2. Tcpdumps of what exactly happens with the current (kind of) working
>> configuration.
>>
>> This has /etc/network/interfaces like:
>> iface eth0 inet static
>>          address 89.233.14.34
>>          network 89.233.14.32/28
>>          broadcast 89.233.14.47
>>          netmask 255.255.255.240
>>          gateway 89.233.14.33
>>
>> In this case everything works as it used to regarding forwarding of IP
>> 89.233.14.34 to addresses on the DMZ (e.g. 89.233.14.34 to
>> 192.168.201.12), but when I try and connect from outside to other IPs
>> that should be forwarded to hosts on the local net, as 89.233.14.37 to
>> 192.168.37.37 or even port 22 for 89.233.14.40  to the same DMZ host
>> 192.168.201.12, what happens is that no ARP answer is sent back from
>> eth0 to the gateway to begin with, hence no packets ever arrive to eth0.
>>
>> An image of wireshark with arp filter on a tcpdump file is attached,
>> showing a series of ARP requests from the gateway and no answer, apart
>> from when the request is about the 89.233.14.34 address.
>>
> You need to configure 'virtual' interfaces. Here's a snippet from my
> /etc/network/interfaces file:
>
> #
> # Commcast Business Class
> #
> auto eth1 eth1:1 eth1:2
> iface eth1 inet static
>          address 70.90.191.121
>          netmask 255.255.255.248
>          network 70.90.191.120
>          broadcast 70.90.191.127
>
> iface eth1:1 inet static
>          address 70.90.191.122
>          netmask 255.255.255.248
>          network 70.90.191.120
>          broadcast 70.90.191.127
>
> iface eth1:2 inet static
>          address 70.90.191.123
>          netmask 255.255.255.248
>          network 70.90.191.120
>          broadcast 70.90.191.127
>
> The primary IP address is 70.90.191.121 and I've configured two more
> addresses from by 70.90.191.120/29 assigned subnet (the other two are
> assigned to servers in my DMZ).
>
> -Tom
>
Aha, thank you. Yes, the idea had touched my mind (apparently not enough 
to try it out though), and this was not necessary (not even possible) 
previously because the setup was not routed, right?

I still do not understand the meaning of the section of the 
documentation about routed/non routed, and assigning "the gateway 
address as the IP address the firewall's external interface" though.
I can live with that of course (although it bothers me) but maybe others 
will be puzzled by it like me.

Anyway, thank you so much for your help that gets me going once again 
(the last time was some years ago, when we again had to make some major 
changes to our network) and for authoring and maintaining shorewall for 
so many years.
/paolo


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to