Am 25.09.18 um 10:21 schrieb Boris:
> Am 25.09.2018 um 00:50 schrieb Tom Eastep:
>> On 09/24/2018 01:55 PM, Boris wrote:
>>> Am 24.09.2018 um 19:12 schrieb Tom Eastep:
>>>> On 09/05/2018 08:16 AM, Boris wrote:
>>>>> Hej SW-list,
>>>>>
>>>>> This is the first time that I'm writing directly to the SW list. First
>>>>> of all, I want to thank you for this great software! I can hardly
>>>>> believe that I have been using SW for more than 15 years - embedded in
>>>>> the also great environment of LEAF (Linux Embedded Appliance Framework
>>>>> (formerly Firewall)).
>>>>>
>>>>> And now, for the first time, I have a problem that I don't understand
>>>>> and hope for help:
>>>>> My LEAF box (Ver. 6.x with SW 5.1.7.2 on Alix hardware) worked great on
>>>>> a VDSL internet line with 25 Mbps / 5Mbps. I used a FritzBox 7490 as
>>>>> modem (PassThrough). I have a web server and a mail server in a DMZ
>>>>> segment, a few desktop PCs in the LAN segment and a few wireless devices
>>>>> in a WLAN segment. The box also serves as an OpenVPN server. Nothing
>>>>> really extraordinary, I think.
>>>>>
>>>>> A few hours ago I got a new internet line switched with higher
>>>>> bandwidth. Unfortunately, I don't (yet) have any detailed technical
>>>>> specifications for the line other than the bandwidth (100Mbps / 40Mbps).
>>>>> A new FritzBox 7590 serves as modem. During a conversation with the
>>>>> support of the provider the keyword 'VLAN 7' was mentioned. This seems
>>>>> to indicate a BNG connection from Telekom, but I didn't have to set up
>>>>> VLAN tagging.
>>>>>
>>>>> Now to the problem description: With the unchanged SW configuration,
>>>>> REJECTS of TCP packets from and to the zone 'net' occur, which were
>>>>> transported correctly before the switchover! It looks like some packets
>>>>> are passing through sporadically, but I can't secure that and I can't
>>>>> even reproduce it. All other zones work fine with each other, so
>>>>> loc-wlan, wlan-dmz, dmz-loc and so on. In addition, icmp packets are
>>>>> transported over the zone net without any problems.
>>>>> In order to be able to use my environment, I removed all restrictions as
>>>>> a temporary solution, with a global statement in /shorewall/policy:
>>>>> all     all      ACCEPT
>>>>> This is of course undesirable and I am looking for the cause of the
>>>>> problem. I asked the provider for detailed specifications of the line.
>>>>> Maybe someone has an idea here? I deactivated the global ACCEPT again
>>>>> and made a dump, which is attached.
>>>>>
>>>>> Many thanks and many greetings,
>>>>>
>>>>>
>>>>
>>>> Your internet interface is now eth0, not ppp0. So you need to change
>>>> your configuration.
>>>>
>>>> -Tom
>>>>
>>>
>>> Hej Tom,
>>>
>>> thank you very much for your statement!
>>>
>>> I'm sure you have one or more very good reason to come to this
>>> conclusion. Could you please give a little explanation?
>>>
>>> Finally, I'm afraid you missunderstood my description of the situation.
>>>
>>> ppp is still doing the login and ppp0 is the interface that 'owns' the
>>> public IP:
>>>
>>> # ip addr sh:
>>>
>>> [snip]
>>> 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>>> state UNKNOWN group default qlen 1000
>>>     link/ether 00:0d:b9:13:fb:d8 brd ff:ff:ff:ff:ff:ff
>>> [snip]
>>> 13: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc
>>> pfifo_fast state UNKNOWN group default qlen 3
>>>     link/ppp
>>>     inet 217.70.192.188 peer 213.178.81.101/32 scope global ppp0
>>>        valid_lft forever preferred_lft forever
>>>
>>> Of course I tried to follow your hint and changed ppp0 into eth0 in
>>> /etc/shorewall/interfaces and /etc/shorewall/snat. Did I miss something
>>> to change?
>>> As result, no client in loc, wlan or dmz could connect to any host in
>>> net. So I switched back....
>>>
>>
>> Okay. I looked at the log messages and assumed that eth0 was the net
>> interface since all of the messages:
>>
>> a) Had eth0 as the source interface.
>> b) Were created out of the INPUT or FORWARD chain.
>>
>> This is an indication that eth0 is not defined to Shorewall yet packets
>> are being received on that interface. This is very strange since eth0
>> doesn't even have an IP address. Given that all of the logged packets
>> are apparently response packets, it would seem that response IP packets
>> are being sent to your firewall from the Fritzbox rather than (or in
>> addition to) being sent via PPPoE. That is why an all->all policy of
>> ACCEPT is allowing your firewall to work.
>>
>> If that analysis is correct, then the problem is not in your Shorewall
>> configuration but in the configuration of PPPoE link.
>>
>> -Tom
> 
> Hej Tom,
> 
> thanks again for your brainwork!
> 
> This is extremely interesting and seems to be the one and only
> explanation for the strange behaviour. I will think it over and
> hopefully create an idea of how to handle.
> 

Hej Tom,
hej list,

here I am again after some weeks of discussions with AVM and the ISP -
with no success nor solution.
Also, I took a break working on this because I'm quite frustrated. But
after all, there should be a way to make the shorewall work again. It's
not a good feeling without safety on that level....

AVM admits the fact that pppoe is not passed directly through. So I hope
(an actually this seems to be the last chance) there might be a
workaround on teh LEAF-box, maybe directly in ShoreWall. Is it possible
to define eth0 there as a kind of incoming-only interface?

In my imagination there could be something like a
forwarding-packet-relay from th0 to ppp0 so that SW accepts the respose
packets on ppp0. But I have no idea how this could be realized....

I would be extremly glad about any idea to solve that tricky problem!

Thanks in advance,


Boris


_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to