Am 14.11.18 um 19:01 schrieb Tom Eastep: > On 11/13/18 3:09 AM, Boris wrote: >> 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! >> > > You can assign a zone (call it 'hack') to eth0 then add these policies: > > hack all ACCEPT > all hack REJECT <log level> >
Hej Tom, thank you VERY much for this! I will try this the next days and give report. Boris _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
