Am 16.11.18 um 00:58 schrieb Timo Sigurdsson: > bo...@cation.de schrieb am 14.11.2018 08:10: > >> Am 2018-11-14 01:06, schrieb Timo Sigurdsson: >>> Boris schrieb am 13.11.2018 12:09: >>> >>>> 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 >>> >>> >>> Hi Boris, >>> >>> is there any particular reason why you want to use the AVM Fritz!Box >>> 7590 as a modem other than that you may have gotten it for free by >>> your provider? >>> >>> From the little experience I have with AVM's boxes, I know that 1) if >>> they support PPPoE passthrough, it's often quirky and 2) don't take >>> it for granted since they might decide to remove PPPoE Passthrough >>> support in a future firmware release as they've done in the past. >>> So, it usually wouldn't cross my mind to use an AVM router as a modem. >>> >>> In addition, the documentation of the 7590 in particular already >>> implies that their PPPoE Passthrough mode does *not* reduce the >>> device to a modem, but rather it allows you to open a *second* >>> PPPoE connection. The 7590 will in any case at least try to open >>> a PPPoE connection for itself [1]. Personally, that looks just >>> like a mess to me if I had such a setup in front of my firewall. >>> >>> I would at least try another device that can be used as a modem >>> and see whether that solves your issues. I can recommend getting >>> a used "Telekom Speedport Entry 2" (I got mine for about 15€, >>> which is a steal). It can be put into a "modem mode" leaving the >>> configuration of the PPPoE connection - including the VLAN >>> tagging - fully up to you and supports VDSL up to 100MBit/s. >>> >>> Regards, >>> >>> Timo >>> >>> [1] >>> https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publication/show/3232_PPPoE-Passthrough-in-FRITZ-Box-einrichten/ >> >> Hej Timo, >> hej list, >> >> Thank you for your statement! >> >> Well, yes, I got the AVM Box for free but there are some reasons I like >> to use it: >> >> 1. It worked fine with a 7390 and I don't want to change too much. >> 2. I use two pppOE-Accounts: One with the AVM Box (dynamic IP) and one >> with the LEAF box behind the Fritzbox (static IP). With that, I can have >> a look on my LAN and DMZ 'from outside'. >> 3. The AVM Box does the VoIP business and so the telephone stuff is >> seperated >> >> Do you think the Speedport Entry 2 can work in that way? I'd be afraid >> the Speedport is modem-only and not capable of being used as VoIP-box >> with a second pppOE-login. >> >> Thanks, >> >> >> Boris > > > Hi Boris, > > no, unfortunately the Speedport Entry 2 can't work in that way - at > least I think so. I don't know of any VDSL modems that can do multiple > PPPoE connections at the same. But then again, that was never something > I looked for. I leave the VoIP stuff to a seperate box in an isolated > network segment *behind* my Shorewall firewall. > > Now, regarding your issue. Have you tried to set up VLAN tagging for > the PPPoE connection on your LEAF box to see whether that changes the > behaviour?
Hej Timo, thanks for your reply! Well, the Fritzbox 7390 did it (login with ppp to the ISP _and_ passthrough ppp to let the LEAF box login, too)! And the 7590 _almost_ does as well.... I thought about a dedicated VoIP-Box behind the Fritzbox. Sure this works. But I still like the idea with the two logins for its two public IPs and the possibility to communicate from one to the other. Yes, I tried with VLAN config on the LEAF box but didn't get connection. The Fritzbox definitely translates from tagged VLAN outside to untagged LAN. So far, Boris _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
