On 5/10/2020 12:29 AM, Boris wrote: > Hello Shorewall – List, > > > first thank you all for caring about Shorewall and thank you Tom for > postponing your retirement! > > Since months I am dragging out the work on an issue that came up after > upgrading a router box based on the PC-Engines ALIX from LEAF 4.x > (extremely outdated) with Shorewall 3.4.8 to LEAF 6.1.3 with Shorewall > 5.2.3.4. > The dragging out is because the box is in far distance from me and there > are only rare hours when I can do experiments with a helping hand on > site. So far, we stepped back to the old version by simply mounting the > old CF-Card the box is booting from. > Next chance to make tests and analysis will be hopefully on tuesday > evening – in four days..... > > The box is connected to a Telekom allIP (DeutschlandLAN IP) Service by a > Zyxel VMG1312 box and regulates the traffic of two LAN segments (loc67 > with internet access and loc66 without) and a WLAN. The Zyxel is > configured as 'pass-through', only decodes the VLAN 7 from Telekom. > > For those who don‘t know LEAF Bering uClibc (leaf.zetam.org): It‘s a > very redommendable small distrubution that is develloped for secure > routers and embedded devices. It‘s running since more than a decade in > some environments I built for friends and collegues. > > Back to the issue: > For LEAF 6.2.3 I did my best to take over the configuration. The > majority of features just works fine – excluded VoIP and receiving Email > from 1und1 (IONOS) while receiving Email T-Online.de from works well. > > First the VoIP: > > Part of the local segment with internet access is a FritzBox 7490 > (192.168.67.253) that works as VoIP gateway. Two ISDN-phones are > connected to that FritzBox, more precise one phone an one fax. > > The VoIP stuff is configured in shorewall by those rules: > > # IP-Telefonie > ACCEPT fw loc udp 5070,5080,30000:31000,40000:41000 > ACCEPT loc fw udp 5060,3478,3479,30000:31000,40000:41000 > DNAT net loc:192.168.67.253 udp 5060 - all > DNAT net loc:192.168.67.253 udp 3478 - all > DNAT net loc:192.168.67.253 udp 3479 - all > DNAT net loc:192.168.67.253 udp 30000:31000 - all > DNAT net loc:192.168.67.253 udp 40000:41000 - all > > Calling from outside to the mentioned phone behind the FritzBox is well > working. > Calling from inside to outside, the phonecall is connected, but there is > no audio transport in both directions. > > The tcpdump on the internal interface (for the good case) looks like > > 18:06:48.195793 IP 192.168.67.253.7078 > 217.0.5.245.27954: UDP, length 172 > 18:06:48.210806 IP 217.0.5.245.27954 > 192.168.67.253.7078: UDP, length 172 > 18:06:48.215785 IP 192.168.67.253.7078 > 217.0.5.245.27954: UDP, length 172 > 18:06:48.230837 IP 217.0.5.245.27954 > 192.168.67.253.7078: UDP, length 172 > > and for the bad case > > 18:07:00.365271 IP 192.168.67.253.7078 > 217.0.5.245.40564: UDP, length 172 > 18:07:00.385216 IP 192.168.67.253.7078 > 217.0.5.245.40564: UDP, length 172 > 18:07:00.405225 IP 192.168.67.253.7078 > 217.0.5.245.40564: UDP, length 172 > 18:07:00.425197 IP 192.168.67.253.7078 > 217.0.5.245.40564: UDP, length 172 > > There aren't any drops or rejects in shorewall.log. > > Looking on the WAN-Interface: > The communication takes place between a SIP host of the Telekom > (217.0.21.128) and the Fritzbox in the zone loc67 (192.168.67.253), > where the phone is attached. > > https://cation.de/pub/Screenshot_1.png > https://cation.de/pub/Screenshot_2.png > > (Sorry I can only show Screenshots of Wireshark) > > Here is my view on the matter: > In Screenshot_1 one can see a recording of the traffic on ppp0. The > marked packet (SIP/SDP (Session Description)) describes how the further > traffic should be handled, namely via port 7078 - RTP. > > Two packets later the first RTP:7078 packet arrives but is not forwarded > to eth1 - see Screenshot_2, recording of traffic on eth1. > > It seems there might be trouble with the IP helpers. So I checked the > helper settings: > > $ less /etc/shorewall/shorewall.conf | grep HELP > AUTOHELPERS=Yes > HELPERS= > > and > > $ lsmod | grep sip > nf_nat_sip 20480 0 - Live 0xc0ac7000 > nf_nat 20480 11 > nf_nat_masquerade_ipv4,xt_nat,nf_nat_ipv4,nf_nat_tftp,nf_nat_sip,nf_nat_pptp,nf_nat_proto_gre,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda, > Live 0xc0aa5000 > nf_conntrack_sip 20480 3 nf_nat_sip, Live 0xc0a8b000 > nf_conntrack 77824 29 > ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_nat,nf_nat_ipv4,xt_CT,nf_conntrack_ipv4,xt_conntrack,nf_nat_tftp,nf_nat_snmp_basic,nf_conntrack_snmp,nf_nat_sip,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,nf_nat,nf_conntrack_amanda,nf_conntrack_sane,nf_conntrack_tftp,nf_conntrack_sip,nf_conntrack_pptp,nf_conntrack_proto_gre,nf_conntrack_netlink,nf_conntrack_netbios_ns,nf_conntrack_broadcast,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_ftp, > Live 0xc0a77000 > > So far the VoIP trouble. > > Looking on the next matter: Email – I beleive the trouble comes from the > same reason….. > > On a Windows10-PC in the zone loc67, there is Thunderbird installed. > Thunderbird pulls mails by pop from a t-online-server correctly but > refuses to pull mails from 1und1. It connects, gets information about > how many new mails there are, but does not download them. smptp works fine. > > > That‘s it. Sorry for the description is quite rough. I will do a > documentation like it is proposed in the Problem Reporting Guidelines > with shorewall dump in some days, but maybe there is one of you have a > hint for me where to have a look at or what to do…. >
Are you sure that Shorewall is the issue? -- Matt Darfeuille <m...@shorewall.org> Shorewall Project Committee, one of four core members https://sourceforge.net/p/shorewall/mailman/message/36596609/ https://shorewall.org _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
