Hi,
Well, I'm back...
This time, I tried replacing my old internal shorewall firewall with a new one
(host name "inf-fw2" with IP addr. 10.215.144.91).
This router controls access to several zones, and most of the traffic was
allowed as expected. However, traffic through the "wan" interface is
On 07/11/2017 12:56 AM, Vieri Di Paola via Shorewall-users wrote:
> Hi,
>
> Well, I'm back...
>
> This time, I tried replacing my old internal shorewall firewall with a new
> one (host name "inf-fw2" with IP addr. 10.215.144.91).
>
Sorry to be so slow responding, but I am traveling this week.
From: Tom Eastep
> Sorry to be so slow responding, but I am traveling this week. Probably> won't
> be able to look at it until the weekend.
So am I.I won't be able to make any changes for the next 2 weeks, so please
take your time.Enjoy your weekend.
Vieri
From: Tom Eastep
>>
>> Sorry to be so slow responding, but I am traveling this week. Probably
>> won't be able to look at it until the weekend.
>
> So am I.
> I won't be able to make any changes for the next 2 weeks, so please take your
> time.
> Enjoy your week
On 07/28/2017 08:37 AM, Vieri Di Paola via Shorewall-users wrote:
>
>
>
> From: Tom Eastep
>>>
>>> Sorry to be so slow responding, but I am traveling this week. Probably
>>> won't be able to look at it until the weekend.
>>
>> So am I.
>> I won't be able to make
From: Tom Eastep
>
> Unfortunately, the FW2 configuration has the same shortcoming as did FW1
> - namely, that there are DROP policies that don't log. So it isn't
> possible to see what is being dropped and I was unable to come to any
> conclusion...
Hi,
I set
On 08/01/2017 12:58 AM, Vieri Di Paola via Shorewall-users wrote:
>
> From: Tom Eastep
>
>>
>> Unfortunately, the FW2 configuration has the same shortcoming as
>> did FW1 - namely, that there are DROP policies that don't log. So
>> it isn't possible to see what i
From: Tom Eastep
>> I'm logging everything, even ACCEPTs, but I don't see anything being
>> dropped regarding the failing pings. I only see "lan-wan ACCEPT"
>> messages for my ICMP tests.
>
> Then the next step is to determine if the requests are actually being
>
On 08/01/2017 09:16 AM, Vieri Di Paola via Shorewall-users wrote:
>
>
>
> From: Tom Eastep
>>> I'm logging everything, even ACCEPTs, but I don't see anything being
>>> dropped regarding the failing pings. I only see "lan-wan ACCEPT"
>>> messages for my ICMP tests
From: Tom Eastep
>> I will be running the following command as soon as I can:
>>
>> # tcpdump -nni enp6s0 icmp
>
> That should do it,
I'm really sorry to keep this thread alive for so long, but I'm in a nasty
predicament.
Here's the test I performed while tryi
From: Vieri Di Paola via Shorewall-users
>
> # tcpdump -nni enp6s0 icmp
I think I just found a solution, but I still need to understand why.
I had to add proxyarp=1 to the wan interface in "interfaces". Pings to wan
hosts started working.
Funny thing is that
On 08/02/2017 06:02 AM, Vieri Di Paola via Shorewall-users wrote:
>
>
> From: Vieri Di Paola via Shorewall-users
>
>>
>> # tcpdump -nni enp6s0 icmp
>
>
> I think I just found a solution, but I still need to understand why.
>
> I had to add proxyarp=1 to the wa
From: Tom Eastep
>
> A current dump of fw1 might shed some light on that...
Just to clear things up a little, here's the current network:
providers --- gw1 (shorewall gateway) --- fw{1,2} (shorewall firewall router)
where
- fw1 was the "old" firewall
- fw2 i
On 08/04/2017 04:28 AM, Vieri Di Paola via Shorewall-users wrote:
>
>
> From: Tom Eastep
>>
>> A current dump of fw1 might shed some light on that...
>
>
> Just to clear things up a little, here's the current network:
>
> providers --- gw1 (shorewall gateway) -
From: Tom Eastep
>
> Here is the main routing table on gw1:
> 10.215.0.0/16 dev enp11s0 proto kernel scope link src 10.215.144.92
>
> Note the last route. It assumes that the entire 10.215.0.0/16 network is
> directly attached to enp11s0.
>
> Here is the main ta
From: Vieri Di Paola via Shorewall-users
>
> So if I wanted to avoid using proxy arp on the WAN interface, and since the
> bulk 10.215.0.0/16 is
> really on the LAN interface then I could change gw1's enp11s0 IP settings to
> 10.215.144.92/32 with a
> route
On 08/07/2017 01:52 AM, Vieri Di Paola via Shorewall-users wrote:
>
>
> From: Vieri Di Paola via Shorewall-users
>
>>
>
>> So if I wanted to avoid using proxy arp on the WAN interface, and since the
>> bulk 10.215.0.0/16 is
>
>> really on the LAN interface th
From: Tom Eastep
>> Here's what I did in gw1's snat file:
>>
>> SNAT($IF_LAN_MASQ_ADDRESS) $IF_LAN_MASQ_SOURCE $IF_LAN
>>
>> The params file contains:
>>
>> IF_LAN=enp11s0
>> IF_LAN_MASQ_ADDRESS=10.215.144.92
>> IF_LAN_MASQ_SOURCE=172.16.0.2
>
> You
On 08/07/2017 11:16 AM, Vieri Di Paola via Shorewall-users wrote:
>
>
> From: Tom Eastep
>
>>> Here's what I did in gw1's snat file:
>>>
>>> SNAT($IF_LAN_MASQ_ADDRESS) $IF_LAN_MASQ_SOURCE $IF_LAN
>>>
>>> The params file contains:
>>>
>>> IF_LAN=enp11s0
>
From: Tom Eastep
>
> there is no evidence in the dump that your rule was present.
Here's part of the output of shorewall -vv check:
Checking /etc/shorewall/snat...
[...]
Snat record "SNAT(10.215.144.92) 172.16.0.2 enp11s0" Checked
However, the following yield
I can see the light at the end of the tunnel, but I'm not quite there yet.
A reminder of my current network:
Internet providers --- gw1 --- fw2 --- lan, dmz, caib, ibs
I replaced the old fw1 with the new fw2 this morning, and everything seemed to
work until I found that some lan hosts could n
From: Vieri Di Paola via Shorewall-users
>
> lan $IF_LAN routeback,arp_filter=1
> wan $IF_WAN routeback,arp_filter=1
> caib$IF_CAIBarp_filter=1
> ibs $IF_IBS arp_filter=1
> dmz $IF_DMZ routeback,dhcp
> -
22 matches
Mail list logo
