You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(93) |
Nov
(89) |
Dec
(68) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(229) |
Feb
(204) |
Mar
(314) |
Apr
(380) |
May
(367) |
Jun
(244) |
Jul
(300) |
Aug
(505) |
Sep
(359) |
Oct
(531) |
Nov
(427) |
Dec
(390) |
2003 |
Jan
(585) |
Feb
(623) |
Mar
(412) |
Apr
(315) |
May
(480) |
Jun
(394) |
Jul
(544) |
Aug
(768) |
Sep
(602) |
Oct
(680) |
Nov
(499) |
Dec
(398) |
2004 |
Jan
(407) |
Feb
(400) |
Mar
(410) |
Apr
(576) |
May
(619) |
Jun
(424) |
Jul
(513) |
Aug
(404) |
Sep
(433) |
Oct
(455) |
Nov
(550) |
Dec
(659) |
2005 |
Jan
(450) |
Feb
(472) |
Mar
(443) |
Apr
(465) |
May
(434) |
Jun
(273) |
Jul
(518) |
Aug
(484) |
Sep
(380) |
Oct
(400) |
Nov
(351) |
Dec
(265) |
2006 |
Jan
(335) |
Feb
(462) |
Mar
(498) |
Apr
(398) |
May
(280) |
Jun
(273) |
Jul
(229) |
Aug
(377) |
Sep
(201) |
Oct
(279) |
Nov
(247) |
Dec
(229) |
2007 |
Jan
(301) |
Feb
(190) |
Mar
(281) |
Apr
(444) |
May
(394) |
Jun
(247) |
Jul
(259) |
Aug
(391) |
Sep
(219) |
Oct
(306) |
Nov
(307) |
Dec
(257) |
2008 |
Jan
(256) |
Feb
(248) |
Mar
(330) |
Apr
(219) |
May
(194) |
Jun
(179) |
Jul
(183) |
Aug
(116) |
Sep
(260) |
Oct
(204) |
Nov
(274) |
Dec
(228) |
2009 |
Jan
(251) |
Feb
(160) |
Mar
(178) |
Apr
(196) |
May
(189) |
Jun
(239) |
Jul
(92) |
Aug
(155) |
Sep
(147) |
Oct
(169) |
Nov
(159) |
Dec
(205) |
2010 |
Jan
(63) |
Feb
(230) |
Mar
(94) |
Apr
(103) |
May
(113) |
Jun
(149) |
Jul
(158) |
Aug
(203) |
Sep
(255) |
Oct
(138) |
Nov
(122) |
Dec
(108) |
2011 |
Jan
(93) |
Feb
(100) |
Mar
(153) |
Apr
(175) |
May
(349) |
Jun
(210) |
Jul
(176) |
Aug
(179) |
Sep
(148) |
Oct
(151) |
Nov
(102) |
Dec
(83) |
2012 |
Jan
(179) |
Feb
(125) |
Mar
(211) |
Apr
(164) |
May
(195) |
Jun
(160) |
Jul
(137) |
Aug
(159) |
Sep
(214) |
Oct
(189) |
Nov
(71) |
Dec
(90) |
2013 |
Jan
(161) |
Feb
(99) |
Mar
(190) |
Apr
(133) |
May
(119) |
Jun
(97) |
Jul
(116) |
Aug
(109) |
Sep
(213) |
Oct
(175) |
Nov
(119) |
Dec
(90) |
2014 |
Jan
(104) |
Feb
(105) |
Mar
(125) |
Apr
(119) |
May
(141) |
Jun
(82) |
Jul
(193) |
Aug
(164) |
Sep
(160) |
Oct
(162) |
Nov
(44) |
Dec
(43) |
2015 |
Jan
(92) |
Feb
(67) |
Mar
(117) |
Apr
(67) |
May
(121) |
Jun
(39) |
Jul
(31) |
Aug
(87) |
Sep
(143) |
Oct
(130) |
Nov
(116) |
Dec
(67) |
2016 |
Jan
(66) |
Feb
(78) |
Mar
(127) |
Apr
(148) |
May
(56) |
Jun
(67) |
Jul
(30) |
Aug
(48) |
Sep
(87) |
Oct
(113) |
Nov
(64) |
Dec
(115) |
2017 |
Jan
(95) |
Feb
(73) |
Mar
(166) |
Apr
(27) |
May
(75) |
Jun
(94) |
Jul
(144) |
Aug
(94) |
Sep
(70) |
Oct
(98) |
Nov
(69) |
Dec
(176) |
2018 |
Jan
(140) |
Feb
(112) |
Mar
(68) |
Apr
(68) |
May
(97) |
Jun
(59) |
Jul
(75) |
Aug
(44) |
Sep
(44) |
Oct
(75) |
Nov
(64) |
Dec
(54) |
2019 |
Jan
(107) |
Feb
(100) |
Mar
(30) |
Apr
(31) |
May
(40) |
Jun
(14) |
Jul
(40) |
Aug
(37) |
Sep
(29) |
Oct
(78) |
Nov
(41) |
Dec
(42) |
2020 |
Jan
(43) |
Feb
(91) |
Mar
(86) |
Apr
(38) |
May
(70) |
Jun
(52) |
Jul
(48) |
Aug
(27) |
Sep
(48) |
Oct
(63) |
Nov
(61) |
Dec
(34) |
2021 |
Jan
(26) |
Feb
(4) |
Mar
(1) |
Apr
(5) |
May
(26) |
Jun
(13) |
Jul
(23) |
Aug
(14) |
Sep
(35) |
Oct
(13) |
Nov
(2) |
Dec
(33) |
2022 |
Jan
(32) |
Feb
(28) |
Mar
(29) |
Apr
(23) |
May
(15) |
Jun
(7) |
Jul
(6) |
Aug
(10) |
Sep
(3) |
Oct
|
Nov
(7) |
Dec
(3) |
2023 |
Jan
(7) |
Feb
(7) |
Mar
(6) |
Apr
(23) |
May
(1) |
Jun
(7) |
Jul
(4) |
Aug
(7) |
Sep
|
Oct
(27) |
Nov
(4) |
Dec
|
2024 |
Jan
(5) |
Feb
(28) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(10) |
Oct
|
Nov
|
Dec
|
From: Robert K C. J. -I. F. D. Corp. <bco...@in...> - 2024-09-03 20:13:14
|
<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>Good deal!</p> <p>Yes, routeback :)</p> <p>- Robert<br> </p> <div class="moz-cite-prefix">On 9/3/2024 3:46 PM, <a class="moz-txt-link-abbreviated" href="mailto:rc...@ed...">rc...@ed...</a> wrote:<br> </div> <blockquote type="cite" cite="mid:7d8...@ed...">Hi to all!! <br> <br> now is working! <br> <br> read all again and detect the error. <br> <br> Thx for all. <br> <br> El 2024-09-03 15:27, <a class="moz-txt-link-abbreviated" href="mailto:rc...@ed...">rc...@ed...</a> escribió: <br> <blockquote type="cite">HI! <br> <br> I found FAQ2 and check de URL and dont work. <br> <br> Shorewall is 5.1.10 <br> <br> i try with SNAT and the rule like: <br> <br> DNAT loc loc:192.168.1.5 tcp www - <br> 130.151.100.69 <br> <br> The rule with DNAT for external call and work well. <br> <br> DNAT wan loc:192.168.1.5 tcp www - <br> 130.151.100.69 <br> <br> i dont see the correct combination, somebody have a rules working for this case? <br> <br> Thx to all. <br> <br> <br> El 2024-09-03 14:40, Benny Pedersen escribió: <br> <blockquote type="cite"><a class="moz-txt-link-abbreviated" href="mailto:rc...@ed...">rc...@ed...</a> skrev den 2024-09-03 19:54: <br> <br> <blockquote type="cite"> <blockquote type="cite">how to put a rule for access a DNAT server from LAN? <br> </blockquote> </blockquote> <br> tread same here <br> <br> <a class="moz-txt-link-freetext" href="https://serverfault.com/questions/403626/how-to-dnat-to-different-local-ip-based-on-what-public-ip-was-accessed-with-shor">https://serverfault.com/questions/403626/how-to-dnat-to-different-local-ip-based-on-what-public-ip-was-accessed-with-shor</a> <br> <br> <blockquote type="cite"> <blockquote type="cite">i try to search how without success <br> </blockquote> </blockquote> <br> man 5 shorewall-nat <br> <br> <br> _______________________________________________ <br> Shorewall-users mailing list <br> <a class="moz-txt-link-abbreviated" href="mailto:Sho...@li...">Sho...@li...</a> <br> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/shorewall-users">https://lists.sourceforge.net/lists/listinfo/shorewall-users</a> <br> </blockquote> <br> <br> _______________________________________________ <br> Shorewall-users mailing list <br> <a class="moz-txt-link-abbreviated" href="mailto:Sho...@li...">Sho...@li...</a> <br> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/shorewall-users">https://lists.sourceforge.net/lists/listinfo/shorewall-users</a> <br> </blockquote> <br> <br> _______________________________________________ <br> Shorewall-users mailing list <br> <a class="moz-txt-link-abbreviated" href="mailto:Sho...@li...">Sho...@li...</a> <br> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/shorewall-users">https://lists.sourceforge.net/lists/listinfo/shorewall-users</a> <br> </blockquote> <pre class="moz-signature" cols="72">-- Robert K Coffman Jr. Info From Data Corp. 3307249000 <a class="moz-txt-link-abbreviated" href="mailto:su...@in...">su...@in...</a></pre> </body> </html> |
From: <rc...@ed...> - 2024-09-03 19:46:26
|
Hi to all!! now is working! read all again and detect the error. Thx for all. El 2024-09-03 15:27, rc...@ed... escribió: > HI! > > I found FAQ2 and check de URL and dont work. > > Shorewall is 5.1.10 > > i try with SNAT and the rule like: > > DNAT loc loc:192.168.1.5 tcp www - > 130.151.100.69 > > The rule with DNAT for external call and work well. > > DNAT wan loc:192.168.1.5 tcp www - > 130.151.100.69 > > i dont see the correct combination, somebody have a rules working for > this case? > > Thx to all. > > > El 2024-09-03 14:40, Benny Pedersen escribió: >> rc...@ed... skrev den 2024-09-03 19:54: >> >>>> how to put a rule for access a DNAT server from LAN? >> >> tread same here >> >> https://serverfault.com/questions/403626/how-to-dnat-to-different-local-ip-based-on-what-public-ip-was-accessed-with-shor >> >>>> i try to search how without success >> >> man 5 shorewall-nat >> >> >> _______________________________________________ >> Shorewall-users mailing list >> Sho...@li... >> https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users |
From: Boris <bo...@ca...> - 2024-09-03 19:42:53
|
Am 03.09.24 um 19:54 schrieb rc...@ed...: > >> Hi! >> how to put a rule for access a DNAT server from LAN? >> i try to search how without success >> Thx > Hej, you should open a new thread for a question different from the original posting. Also, you should provide little more information about your architecture. Is the webserver in a DMZ? Boris |
From: <rc...@ed...> - 2024-09-03 19:27:21
|
HI! I found FAQ2 and check de URL and dont work. Shorewall is 5.1.10 i try with SNAT and the rule like: DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69 The rule with DNAT for external call and work well. DNAT wan loc:192.168.1.5 tcp www - 130.151.100.69 i dont see the correct combination, somebody have a rules working for this case? Thx to all. El 2024-09-03 14:40, Benny Pedersen escribió: > rc...@ed... skrev den 2024-09-03 19:54: > >>> how to put a rule for access a DNAT server from LAN? > > tread same here > > https://serverfault.com/questions/403626/how-to-dnat-to-different-local-ip-based-on-what-public-ip-was-accessed-with-shor > >>> i try to search how without success > > man 5 shorewall-nat > > > _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users |
From: Benny P. <me...@ju...> - 2024-09-03 19:00:19
|
rc...@ed... skrev den 2024-09-03 19:54: >> how to put a rule for access a DNAT server from LAN? tread same here https://serverfault.com/questions/403626/how-to-dnat-to-different-local-ip-based-on-what-public-ip-was-accessed-with-shor >> i try to search how without success man 5 shorewall-nat |
From: <rc...@ed...> - 2024-09-03 18:59:10
|
hi! where is FAQ 2? i dont see in the webpage. Thx El 2024-09-03 14:29, Robert K Coffman Jr. -Info From Data Corp. escribió: > This is FAQ 2. > > On 9/3/2024 1:54 PM, rc...@ed... wrote: > > Hi! > > how to put a rule for access a DNAT server from LAN? > > i try to search how without success > > Thx > > _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users -- Robert K Coffman Jr. Info From Data Corp. 3307249000 su...@in... _______________________________________________ Shorewall-users mailing list Sho...@li... https://lists.sourceforge.net/lists/listinfo/shorewall-users |
From: <rc...@ed...> - 2024-09-03 18:57:58
|
hi, internal access use only external dns. I cant put dns split in this case. I dont remember how with shorewall fix this issue. Thx El 2024-09-03 14:45, Nigel Aves escribió: > If I am reading this correctly, the DNAT server is your gateway, so > make the internal Gateway to that server's LAN address. > > Nigel. > > On Tue, Sep 3, 2024 at 12:12 PM <rc...@ed...> wrote: > > Hi! > > how to put a rule for access a DNAT server from LAN? > > i try to search how without success > > Thx _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users -- Be Safe Out There. Nigel Aves p.s. We have many fine video podcasts on YouTube. These are all interview-based, and pretty well cover every subject. All our shows are here Captn's Lounge Studios [1] Or on YouTube CIT Network [2] Please Subscribe to CIT Come be interviewed: At The Captn's Lounge. [3] _______________________________________________ Shorewall-users mailing list Sho...@li... https://lists.sourceforge.net/lists/listinfo/shorewall-users Links: ------ [1] https://captnslounge.com/ [2] https://www.youtube.com/@citnetwork5407 [3] https://youtu.be/paL0uRkZ69o?si=pUm3pWe8hAXScdC8 |
From: Robert K C. J. -I. F. D. Corp. <bco...@in...> - 2024-09-03 18:50:20
|
<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>This is FAQ 2.<br> </p> <div class="moz-cite-prefix">On 9/3/2024 1:54 PM, <a class="moz-txt-link-abbreviated" href="mailto:rc...@ed...">rc...@ed...</a> wrote:<br> </div> <blockquote type="cite" cite="mid:aed...@ed..."> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <p><br> </p> <blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"> <div class="pre" style="margin: 0; padding: 0; font-family: monospace">Hi!</div> <div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div> <div class="pre" style="margin: 0; padding: 0; font-family: monospace">how to put a rule for access a DNAT server from LAN?</div> <div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div> <div class="pre" style="margin: 0; padding: 0; font-family: monospace">i try to search how without success</div> <div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div> <div class="pre" style="margin: 0; padding: 0; font-family: monospace">Thx</div> </blockquote> <br> <fieldset class="moz-mime-attachment-header"></fieldset> <br> <fieldset class="moz-mime-attachment-header"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ Shorewall-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Sho...@li...">Sho...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/shorewall-users">https://lists.sourceforge.net/lists/listinfo/shorewall-users</a> </pre> </blockquote> <pre class="moz-signature" cols="72">-- Robert K Coffman Jr. Info From Data Corp. 3307249000 <a class="moz-txt-link-abbreviated" href="mailto:su...@in...">su...@in...</a></pre> </body> </html> |
From: Nigel A. <nig...@gm...> - 2024-09-03 18:46:11
|
If I am reading this correctly, the DNAT server is your gateway, so make the internal Gateway to that server's LAN address. Nigel. On Tue, Sep 3, 2024 at 12:12 PM <rc...@ed...> wrote: > > Hi! > > how to put a rule for access a DNAT server from LAN? > > i try to search how without success > > Thx > > _______________________________________________ > Shorewall-users mailing list > Sho...@li... > https://lists.sourceforge.net/lists/listinfo/shorewall-users > -- *Be Safe Out There.* *Nigel Aves* p.s. We have many fine video podcasts on YouTube. These are all interview-based, and pretty well cover every subject. All our shows are here *Captn's Lounge Studios <https://captnslounge.com/>* Or on YouTube CIT Network <https://www.youtube.com/@citnetwork5407> Please Subscribe to *CIT* *Come be interviewed: At The Captn's Lounge. <https://youtu.be/paL0uRkZ69o?si=pUm3pWe8hAXScdC8>* |
From: <rc...@ed...> - 2024-09-03 18:11:44
|
> Hi! > > how to put a rule for access a DNAT server from LAN? > > i try to search how without success > > Thx |
From: Martijn V. <ma...@tr...> - 2024-07-04 08:37:41
|
Hi Paul, Thanks. Because it was becoming a problem on my updated servers (they couldn't keep up), I got the same idea last night. I just implemented it this morning. Because the shorewall allow & drop commands are broadcasted frequently by an ansible (ssh) commands on a cluster of multiple servers, I had to improvise to test this on a specific server. I've moved the current database to an ipset (and increase the default list-length-limit). I added this to the shorewall rules config. I've switched the shorewall executable for a simple bash script (I'm sorry, I'm not with the bash syntax so I guess you'll laugh based on the quality). #!/bin/sh if [ "$1" = "drop" ]; then for ip in "$@" do if [ "$ip" != "drop" ]; then /usr/sbin/ipset add tfblocklist $ip fi done /usr/sbin/ipset save > /etc/iptables/ipsets elif [ "$1" = "allow" ]; then for ip in "$@" do if [ "$ip" != "allow" ]; then /usr/sbin/ipset del tfblocklist $ip fi done /usr/sbin/ipset save > /etc/iptables/ipsets else /usr/sbin/shorewallorig "$@" fi Seems to work alright, performance is great (even better than before). So I think I'll implement this method on the cluster. Using ipset to solve this problem seems like an improvement as it still keep the enormous iptables -L -n list readable. Thanks for you input and provided solution!! Martijn Verhoef Van: Paul Gear via Shorewall-users <sho...@li...> Verzonden: donderdag 4 juli 2024 08:59 Aan: sho...@li... CC: Paul Gear <paul-shorewall@gear.email> Onderwerp: Re: [Shorewall-users] Performance since updating Ubuntu 18.04 to 22.04 and many drop lines Hi Martijn, I've noticed similar things, although it's not a big deal on my system because the number of addresses is much lower. Under recent Ubuntu (and Debian, and I'm sure many other distros) versions, iptables has become a compatibility wrapper around nftables. My guess (only a guess, without any data to back it up) would be that this is the cause. I'd try using ipsets instead to see if this improves your performance; something like: DROP net:+reject $FW REJECT $FW net:+reject in your rules to implement the blocking, and: ipset create -exist reject hash:ip counters hashsize 65536 maxelem 16777216 # tune these numbers to your liking to create the set, and: ipset add reject 1.2.3.4 to add something to the list. I'd be interested to know how you fare with this... On 4/7/24 05:10, Martijn Verhoef via Shorewall-users wrote: Hi, Since I updated Ubuntu, I've been experiencing performance problems when using the 'shorewall drop' command. During the upgrade Ubuntu 18.04 to 22.04, shorewall updated from version 5.1.12.2 to 5.2.3.4 Based on a script, I update my firewall rules every few minutes using a 'shorewall drop <ip1> <ip2> ... && shorewall allow <ip1> <ip2> ...' command. Since the upgrade, I see that it takes approximately 15 seconds per ip-address to process. On my other servers, it takes much less time. Using the process manager, I found out the following 4 commands are executed and take approx. 3-4 seconds each. How is it possible that they take so much time since this update? /sbin/iptables -D dynamic -s <ip> -j reject /sbin/iptables -D dynamic -s <ip> -j DROP /sbin/iptables -D dynamic -s <ip> -j logreject /sbin/iptables -D dynamic -s <ip> -j logdrop ... |
From: Paul G. <pau...@ge...> - 2024-07-04 07:16:13
|
Hi Martijn, I've noticed similar things, although it's not a big deal on my system because the number of addresses is much lower. Under recent Ubuntu (and Debian, and I'm sure many other distros) versions, iptables has become a compatibility wrapper around nftables. My guess (only a guess, without any data to back it up) would be that this is the cause. I'd try using ipsets instead to see if this improves your performance; something like: DROP net:+reject $FW REJECT $FW net:+reject in your rules to implement the blocking, and: ipset create -exist reject hash:ip counters hashsize 65536 maxelem 16777216 # tune these numbers to your liking to create the set, and: ipset add reject 1.2.3.4 to add something to the list. I'd be interested to know how you fare with this... On 4/7/24 05:10, Martijn Verhoef via Shorewall-users wrote: > > Hi, > > Since I updated Ubuntu, I’ve been experiencing performance problems > when using the ‘shorewall drop’ command. > > During the upgrade Ubuntu 18.04 to 22.04, shorewall updated from > version 5.1.12.2 to 5.2.3.4 > > Based on a script, I update my firewall rules every few minutes using > a ‘shorewall drop <ip1> <ip2> … && shorewall allow <ip1> <ip2> …’ command. > > Since the upgrade, I see that it takes approximately 15 seconds per > ip-address to process. On my other servers, it takes much less time. > > Using the process manager, I found out _the following 4 commands are > executed and take approx. 3-4 seconds each._ How is it possible that > they take so much time since this update? > > /sbin/iptables -D dynamic -s <ip> -j reject > > /sbin/iptables -D dynamic -s <ip> -j DROP > > /sbin/iptables -D dynamic -s <ip> -j logreject > > /sbin/iptables -D dynamic -s <ip> -j logdrop > > ... |
From: Martijn V. <ma...@tr...> - 2024-07-03 20:42:23
|
Hi, Since I updated Ubuntu, I've been experiencing performance problems when using the 'shorewall drop' command. During the upgrade Ubuntu 18.04 to 22.04, shorewall updated from version 5.1.12.2 to 5.2.3.4 Based on a script, I update my firewall rules every few minutes using a 'shorewall drop <ip1> <ip2> ... && shorewall allow <ip1> <ip2> ...' command. Since the upgrade, I see that it takes approximately 15 seconds per ip-address to process. On my other servers, it takes much less time. Using the process manager, I found out the following 4 commands are executed and take approx. 3-4 seconds each. How is it possible that they take so much time since this update? /sbin/iptables -D dynamic -s <ip> -j reject /sbin/iptables -D dynamic -s <ip> -j DROP /sbin/iptables -D dynamic -s <ip> -j logreject /sbin/iptables -D dynamic -s <ip> -j logdrop FYI: my iptables list was before update, and still is, approx. 130.000 ip-addresses long, most rules are in the dynamic part, based on this 'shorewall drop' command. As far as I know I haven't changed anything relevant in the shorewall.conf, in attachment. My rules/policy/zones are small and not that interesting as far as I can think of. --- I think this information isn't necessary but because it's requested on the website, hereby: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 3e:d0:64:a4:68:a9 brd ff:ff:ff:ff:ff:ff altname enp0s18 inet <ipv4addr>/26 brd 79.99.130.255 scope global ens18 valid_lft forever preferred_lft forever inet6 <ipv6part>:5::20:5/64 scope global valid_lft forever preferred_lft forever inet6 <ipv6part>:5::20:3/64 scope global valid_lft forever preferred_lft forever inet6 <ipv6part>:5::20:1/64 scope global valid_lft forever preferred_lft forever inet6 <ipv6part>:a::20:1/48 scope global valid_lft forever preferred_lft forever inet6 <ipv6part>:5::20:2/64 scope global valid_lft forever preferred_lft forever inet6 <ipv6part>:5::20:4/64 scope global valid_lft forever preferred_lft forever inet6 fe80::3cd0:64ff:fea4:68a9/64 scope link valid_lft forever preferred_lft forever 3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether c6:6c:32:93:d4:bb brd ff:ff:ff:ff:ff:ff altname enp0s19 inet 192.168.60.30/26 brd 192.168.60.63 scope global ens19 valid_lft forever preferred_lft forever inet6 fe80::c46c:32ff:fe93:d4bb/64 scope link valid_lft forever preferred_lft forever root@hosting20:/etc/shorewall# ip route show default via <ipv4gateway> dev ens18 proto static <ipv4subnet>/26 dev ens18 proto kernel scope link src <ipv4gateway> 192.168.0.0/16 via 192.168.60.1 dev ens19 proto static 192.168.60.0/26 dev ens19 proto kernel scope link src 192.168.60.30 Thanks in advance!! Martijn |
From: Uwe B <sh...@be...> - 2024-03-15 13:59:45
|
On 3/15/24 10:17, Uwe B wrote: > Hello, > > after solving my "dropped icmpv6" issues there still is the issue of the > missing log entries. ... > Is there a way to specify an nflog--group somewhere in the shorewall > configuration so that *all* logs are sent there? > Or is there another solution for this? the solution is to read the man-pages carefully. Coming from a very old version of shorewall (3.xx?) over the years and copying the config files every update, I missed one place where I had not changed LOG_LEVEL="NFLOG" ==> this needs to go and RPFILTER_LOG_LEVEL="$LOG_LEVEL" ==> this needs to be "$LOG" so my LOG="NFLOG(6,0,1)" in params was ignored for certain logs and the NFLOG without parameters logs to group 0... Kind regards, Uwe |
From: Uwe B <sh...@be...> - 2024-03-15 09:17:35
|
Hello, after solving my "dropped icmpv6" issues there still is the issue of the missing log entries. I was lucky that the proxmox logging daemon caught these and I found at least a hint what might be wrong. The pvefw-logger (proxmox) is logging netfilter-group 0 and thus blocking any other logging attempts of that group (solution: disable the daemon). I have configured shorewall logging so that ipV4 is logged in group 4 and ipV6 is logged in group 6: Shorewall: LOG="NFLOG(4)" LOG="NFLOG(6,0,1)" ulogd: stack=log4:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu4:LOGEMU stack=log6:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu6:LOGEMU ... # Using log4 for IPv4 [log4] group=4 numeric_label=4 # Using log6 for IPv6 [log6] group=6 numeric_label=6 attach_conntrack=1 bind=1 ... [emu4] file="/var/log/shorewall.log" sync=1 [emu6] file="/var/log/shorewall6.log" sync=1 ... I could also log group 0 into a separate log, but the better way would be to use the appropriate logs that exist already (emu4, emu6) When analyzing the shorewall6 dump file I noticed that not all NFLOG targets have an associated nflog-group. The ones without a group then get logged to group 0. This is true for ipV4 and ipV6 so they get mixed up in group 0: grep nflog-prefix /tmp/sh6.dump 0 0 NFLOG 0 -- * * ::/0 ::/0 limit: up to 1/sec burst 10 mode srcip nflog-prefix "Sh6:INPUT:DROP:" nflog-group 6 nflog-threshold 1 0 0 NFLOG 0 -- * * ::/0 ::/0 limit: up to 1/sec burst 10 mode srcip nflog-prefix "Sh6:FORWARD:DROP:" nflog-group 6 nflog-threshold 1 0 0 NFLOG 0 -- * * ::/0 ::/0 limit: up to 1/sec burst 10 mode srcip nflog-prefix "Sh6:logflags:DROP:" 0 0 NFLOG 0 -- * * ::/0 ::/0 limit: up to 1/sec burst 10 mode srcip nflog-prefix "Sh6:sfilter:DROP:" 0 0 NFLOG 0 -- * * ::/0 ::/0 limit: up to 1/sec burst 10 mode srcip nflog-prefix "Sh6:smurfs:DROP:" 0 0 NFLOG 0 -- * * ::/0 ::/0 limit: up to 1/sec burst 10 mode srcip nflog-prefix "Sh6:dmz-net:ACCEPT:" nflog-group 6 nflog-threshold 1 0 0 NFLOG 0 -- * * ::/0 ::/0 limit: up to 1/sec burst 10 mode srcip nflog-prefix "Sh6:rplog:DROP:" ... grep nflog-prefix /tmp/sh4.dump 1 60 NFLOG 0 -- * * 0.0.0.0/0 0.0.0.0/0 nflog-prefix "ShW:INPUT:REJECT:" nflog-group 4 2 120 NFLOG 0 -- * * 0.0.0.0/0 0.0.0.0/0 nflog-prefix "ShW:FORWARD:REJECT:" nflog-group 4 0 0 NFLOG 0 -- * * 0.0.0.0/0 0.0.0.0/0 nflog-prefix "ShW:sfilter:DROP:" ... Is there a way to specify an nflog--group somewhere in the shorewall configuration so that *all* logs are sent there? Or is there another solution for this? Kind regards, Uwe |
From: Uwe B <sh...@be...> - 2024-03-14 12:14:45
|
On 3/14/24 12:46, Uwe B wrote: > > So I'm still puzzled how to get rid of the DROP in the rplog chain and > if it would even be a good idea to do so. well, the mystery is solved. Triggered by the "anti-spoofing" description for the rpfilter option in /etc/shorewall6/interfaces: rpfilter Added in Shorewall 4.5.7. This is an anti-spoofing measure that requires the 'RPFilter Match' capability in your iptables and kernel. It provides a more efficient alternative to the sfilter option below. It performs a function similar to routefilter (see above) but works with Multi-ISP configurations that do not use balanced routes. I had this in the interfaces file: ... net AMS2 detect nosmurfs,tcpflags,rpfilter,forward=1 ... without the rpfilter, everything works as designed. Now I only have the issue with the strange logfile location. Kind regards, Uwe |
From: Uwe B <sh...@be...> - 2024-03-14 11:46:44
|
On 3/13/24 18:31, Tuomo Soini wrote: ... > > Note rplog here. That means rpfilter is preventing this packet. That > means you have a problem with routing. > I can't follow. How can routing be dependent on the type of ICMP6 packet? The connection works fine for "normal packets" I did a "shorewall6 dump" and looked at the output. The only places where rplog occurs is in the mangle table, which I did not configure (I have no tcrules or mangle in my /etc/shorewall6), so they must be some default setting: Mangle Table Chain PREROUTING (policy ACCEPT 337 packets, 59636 bytes) pkts bytes target prot opt in out source destination ... 0 0 rplog 0 -- ROT1 * ::/0 ::/0 rpfilter validmark invert ctstate INVALID,NEW,RELATED 0 0 rplog 0 -- AMS2 * ::/0 ::/0 rpfilter validmark invert ctstate INVALID,NEW,RELATED ... Chain rplog (16 references) pkts bytes target prot opt in out source destination 0 0 NFLOG 0 -- * * ::/0 ::/0 limit: up to 1/sec burst 10 mode srcip nflog-prefix "Sh6:rplog:DROP:" 0 0 DROP 0 -- * * ::/0 ::/0 My suspicion was that the connection tracking somehow fails and the incoming packet cannot be associated with a previous packet. But wireshark can follow the entire tcp stream as coherent and also "highlights" the ICMP6 errors (which are dropped by the PREROUTING chain). So I'm still puzzled how to get rid of the DROP in the rplog chain and if it would even be a good idea to do so. And I'm still trying to find out why my setting in ulogd.conf is ignored and logs are sent to this "other" logfile. Documentation is very sparse on this. Kind regards, Uwe |
From: Tuomo S. <ti...@fo...> - 2024-03-13 17:31:34
|
On Wed, 13 Mar 2024 18:00:20 +0100 Uwe B <sh...@be...> wrote: > This tells me that everything works (unfiltered) as it should up to > Interface AMS2. > > In the meantime I noticed that there are entries in a log > (pve-firewall.log) which I did not configure (the system is a proxmox > setup): > 0 6 - 13/Mar/2024:16:19:50 +0000 Sh6:rplog:DROP:IN=AMS2 > SRC=2001:470:1:18::3:1280 DST=fdbf:1d37:bbe0:0:48::35 LEN=1240 TC=0 > FLOWLBL=0 HOPLIMIT=240 PROTO=ICMPV6 TYPE=2 CODE=0 MTU=1280 Note rplog here. That means rpfilter is preventing this packet. That means you have a problem with routing. -- Tuomo Soini <ti...@fo...> Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> |
From: Uwe B <sh...@be...> - 2024-03-13 17:00:44
|
On 3/13/24 16:36, Tuomo Soini wrote: > On Wed, 13 Mar 2024 15:37:31 +0100 > Uwe Behle <sh...@be...> wrote: > >> Good afternoon, >> >> first, the mandatory information; for brevity since the problem lies >> in ipV6, for V6 only: >> >> shorewall6 version >> 5.2.8 > > Shorewall especially has rules to allow required ICMPv6 messages so > shorewall is not blocking those. Only software issue there could be > would be netfilter not being able to relate those icmp packets to your > connection but I'd expect much more than this only to be broken in this > case. > > Because path mtu discovery is completely separate for both > directions in ipv6, issue can be in either end. > > In your case, you send packet over vpn - and sending packet wouldn't > work if you'd block packet too big icmp. So because you can send > packets out, problem is other direction. > > Unlike IPv4, IPv6 does separate path mtu discovery for packets coming > from responder to you, and machine on the other end of VPN is sending > ICMPv6 Packet too big to the server when server try to respond you with > 1500 MTU packet. So most likely packets from your other vpn end are > filtered. That is if I understand your config correctly. > > I know at this time whole azure is broken for IPv6 because they block > packet too big icmpv6. So you can't reach any of their servers with > IPv6 behind VPN. > Hi Tuomo, To clarify the setup: |tunnel-end(AMS2) ----Interface(vmbr2)|___|Interface(eth0)---- browser| machine A machine B My understanding is that when the browser opens test-ipv6.com it loads the necessary java-scripts and then sends packets via these java scripts to remote systems through the network interface eth0 on machine B. This is then forwarded by machine A and SNATted through the tunnel. The diagnosis is then derived from the response to the browser from the returned packets. So for the long packets it uses this (seen in debug-mode of the browser) "GET": { "scheme": "https", "host": "mtu1280.vm3.test-ipv6.com", "filename": "/images-nc/hires_ok.png", "query": { "": "", "fill": "xxxx.... very long string... xxxx" "testdomain": "test-ipv6.com", "testname": "test_v6mtu_img" } } and then expects this "packet too long" resonse, which never arrives until the timeout is reached. I can see this response at my end of the vpn tunnel (AMS2) and would expect it to be un-NATted and forwarded to the originator (the browser java script), which is behind the interface vmbr2. This does not happen. The icmp6 arrives at AMS2 (mach. A) but is never seen at vmbr2 (mach. A) and of course not at eth0 (mach. B) or the browser. This tells me that everything works (unfiltered) as it should up to Interface AMS2. In the meantime I noticed that there are entries in a log (pve-firewall.log) which I did not configure (the system is a proxmox setup): 0 6 - 13/Mar/2024:16:19:50 +0000 Sh6:rplog:DROP:IN=AMS2 SRC=2001:470:1:18::3:1280 DST=fdbf:1d37:bbe0:0:48::35 LEN=1240 TC=0 FLOWLBL=0 HOPLIMIT=240 PROTO=ICMPV6 TYPE=2 CODE=0 MTU=1280 This looks like a smoking gun to me - however I'm puzzled why these are dropped and not logged in my standard logfile... Kind regards, Uwe |
From: Tuomo S. <ti...@fo...> - 2024-03-13 15:53:13
|
On Wed, 13 Mar 2024 15:37:31 +0100 Uwe Behle <sh...@be...> wrote: > Good afternoon, > > first, the mandatory information; for brevity since the problem lies > in ipV6, for V6 only: > > shorewall6 version > 5.2.8 Shorewall especially has rules to allow required ICMPv6 messages so shorewall is not blocking those. Only software issue there could be would be netfilter not being able to relate those icmp packets to your connection but I'd expect much more than this only to be broken in this case. Because path mtu discovery is completely separate for both directions in ipv6, issue can be in either end. In your case, you send packet over vpn - and sending packet wouldn't work if you'd block packet too big icmp. So because you can send packets out, problem is other direction. Unlike IPv4, IPv6 does separate path mtu discovery for packets coming from responder to you, and machine on the other end of VPN is sending ICMPv6 Packet too big to the server when server try to respond you with 1500 MTU packet. So most likely packets from your other vpn end are filtered. That is if I understand your config correctly. I know at this time whole azure is broken for IPv6 because they block packet too big icmpv6. So you can't reach any of their servers with IPv6 behind VPN. -- Tuomo Soini <ti...@fo...> Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> |
From: Uwe B. <sh...@be...> - 2024-03-13 14:37:56
|
Good afternoon, first, the mandatory information; for brevity since the problem lies in ipV6, for V6 only: shorewall6 version 5.2.8 ip -6 addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000 inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fe80::385e:4fff:fe69:a73f/64 scope link valid_lft forever preferred_lft forever 7: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2a02:a00:f010::fb/64 scope global valid_lft forever preferred_lft forever inet6 fe80::2e2:69ff:fe7a:85a2/64 scope link valid_lft forever preferred_lft forever 8: vmbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2a02:a00:f010:3300::fb/64 scope global valid_lft forever preferred_lft forever inet6 fe80::6a:d7ff:fe82:82e5/64 scope link valid_lft forever preferred_lft forever 10: vmbr3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2a02:a00:f010:1000::fb/64 scope global valid_lft forever preferred_lft forever inet6 fe80::2e2:69ff:fe7a:85a2/64 scope link valid_lft forever preferred_lft forever 12: WAR0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:95:1:0:f8/112 scope global valid_lft forever preferred_lft forever inet6 fe80::e838:6fb3:cef7:372c/64 scope link stable-privacy valid_lft forever preferred_lft forever 13: LON6: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:16:2:0:f7/112 scope global valid_lft forever preferred_lft forever inet6 fe80::cd5d:26c1:b9d:b64c/64 scope link stable-privacy valid_lft forever preferred_lft forever 14: NUR7: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:62:3:0:35/112 scope global valid_lft forever preferred_lft forever inet6 fe80::b364:f254:bdcf:b1c7/64 scope link stable-privacy valid_lft forever preferred_lft forever 15: ZUR8: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:89:3:0:30/112 scope global valid_lft forever preferred_lft forever inet6 fe80::a392:109f:83e0:efad/64 scope link stable-privacy valid_lft forever preferred_lft forever 16: AMS2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:48::35/112 scope global valid_lft forever preferred_lft forever inet6 fe80::2317:f225:5833:e2d4/64 scope link stable-privacy valid_lft forever preferred_lft forever 17: STO4: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:65:1:0:f8/112 scope global valid_lft forever preferred_lft forever inet6 fe80::d4b0:4540:2123:6963/64 scope link stable-privacy valid_lft forever preferred_lft forever 19: ERF9: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:11::3b/112 scope global valid_lft forever preferred_lft forever inet6 fe80::3dcd:ddfb:8e0c:a6/64 scope link stable-privacy valid_lft forever preferred_lft forever 21: NEW5: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:20:3:0:f3/112 scope global valid_lft forever preferred_lft forever inet6 fe80::61c6:6de1:fd65:b5af/64 scope link stable-privacy valid_lft forever preferred_lft forever 44: ROT1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:30:2:0:f1/112 scope global valid_lft forever preferred_lft forever inet6 fe80::3955:ef24:ab32:6c9a/64 scope link stable-privacy valid_lft forever preferred_lft forever 45: RIG10: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:27:3:0:f2/112 scope global valid_lft forever preferred_lft forever inet6 fe80::caaa:442f:7a71:57c3/64 scope link stable-privacy valid_lft forever preferred_lft forever 46: OSL11: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500 inet6 fdbf:1d37:bbe0:0:23:2:0:20/112 scope global valid_lft forever preferred_lft forever inet6 fe80::46bf:d4e4:319:5fd3/64 scope link stable-privacy valid_lft forever preferred_lft forever ip -6 route show 2a01:4f9:4b:44c2::2 via fdbf:1d37:bbe0:0:48::1 dev AMS2 metric 1024 pref medium 2a02:a00:f010::/64 dev vmbr1 proto kernel metric 256 pref medium 2a02:a00:f010:1000::/64 dev vmbr3 proto kernel metric 256 pref medium 2a02:a00:f010:3300::111 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::112 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::113 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::115 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::116 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::117 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::118 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::119 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::120 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::121 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::122 dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium 2a02:a00:f010:3300::/64 dev vmbr2 proto kernel metric 256 pref medium 2a02:26f0:280:183::356e via fdbf:1d37:bbe0:0:30:2:0:1 dev ROT1 metric 1024 pref medium 2a02:26f0:280:18d::356e via fdbf:1d37:bbe0:0:30:2:0:1 dev ROT1 metric 1024 pref medium 2a02:26f0:280:190::356e via fdbf:1d37:bbe0:0:30:2:0:1 dev ROT1 metric 1024 pref medium 2a02:26f0:280:192::356e via fdbf:1d37:bbe0:0:30:2:0:1 dev ROT1 metric 1024 pref medium 2a02:26f0:280:193::356e via fdbf:1d37:bbe0:0:30:2:0:1 dev ROT1 metric 1024 pref medium fdbf:1d37:bbe0:0:11::/112 dev ERF9 proto kernel metric 256 pref medium fdbf:1d37:bbe0:0:16:2::/112 dev LON6 proto kernel metric 256 pref medium fdbf:1d37:bbe0:0:20:3::/112 dev NEW5 proto kernel metric 256 pref medium fdbf:1d37:bbe0:0:23:2::/112 dev OSL11 proto kernel metric 256 pref medium fdbf:1d37:bbe0:0:27:3::/112 dev RIG10 proto kernel metric 256 pref medium fdbf:1d37:bbe0:0:30:2::/112 dev ROT1 proto kernel metric 256 pref medium fdbf:1d37:bbe0:0:48::/112 dev AMS2 proto kernel metric 256 pref medium fdbf:1d37:bbe0:0:62:3::/112 dev NUR7 proto kernel metric 256 pref medium fdbf:1d37:bbe0:0:65:1::/112 dev STO4 proto kernel metric 256 pref medium fdbf:1d37:bbe0:0:89:3::/112 dev ZUR8 proto kernel metric 256 pref medium fdbf:1d37:bbe0:0:95:1::/112 dev WAR0 proto kernel metric 256 pref medium fe80::/64 dev vmbr0 proto kernel metric 256 pref medium fe80::/64 dev vmbr2 proto kernel metric 256 pref medium fe80::/64 dev vmbr1 proto kernel metric 256 pref medium fe80::/64 dev vmbr3 proto kernel metric 256 pref medium fe80::/64 dev WAR0 proto kernel metric 256 pref medium fe80::/64 dev LON6 proto kernel metric 256 pref medium fe80::/64 dev NUR7 proto kernel metric 256 pref medium fe80::/64 dev ZUR8 proto kernel metric 256 pref medium fe80::/64 dev AMS2 proto kernel metric 256 pref medium fe80::/64 dev STO4 proto kernel metric 256 pref medium fe80::/64 dev ERF9 proto kernel metric 256 pref medium fe80::/64 dev NEW5 proto kernel metric 256 pref medium fe80::/64 dev ROT1 proto kernel metric 256 pref medium fe80::/64 dev RIG10 proto kernel metric 256 pref medium fe80::/64 dev OSL11 proto kernel metric 256 pref medium default via 2a02:a00:f010::fd dev vmbr1 proto kernel metric 1024 onlink pref medium Problem: I am trying to route and SNAT all ipV6 traffic from a specific server (2a02:a00:f010:3300::113) behind interface vmbr2 through a vpn tunnel (Interface AMS2). for this I have: ----------------------------- ip -6 rule show ... 32756: from 2a02:a00:f010:3300::113 lookup pp6_table2 ... ----------------------------- ip -6 route show table pp6_table2 ::1 dev lo metric 1024 pref medium 2a02:a00:f010::/64 dev vmbr1 metric 1024 pref medium 2a02:a00:f010:3300::113 dev vmbr2 proto kernel src fdbf:1d37:bbe0:0:48::35 metric 1024 pref medium fdbf:1d37:bbe0:0:48::1 dev AMS2 proto kernel src fdbf:1d37:bbe0:0:48::35 metric 1024 pref medium default dev AMS2 metric 1024 pref medium ----------------------------- and in /etc/shorewall6/snat: ----------------------------- ... MASQUERADE 2a02:a00:f010::/48 AMS2 ... ----------------------------- This appears to work for "normal traffic" and "normal pings". Example: ping from server with the 2a02:a00:f010:3300::113 IP: ----------------------------- ping -6 -I 2a02:a00:f010:3300::113 heise.de PING heise.de(redirector.heise.de (2a02:2e0:3fe:1001:302::)) from 2a02:a00:f010:3300::113 : 56 data bytes 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=1 ttl=53 time=22.5 ms 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=2 ttl=53 time=22.5 ms ... ----------------------------- However, not all icmp messages make it back to the originating ip (2a02:a00:f010:3300::113) for instance I see this on the vpn-tunnel interface: ----------------------------- tcpdump -vvv -n -i AMS2 '(ip6 and icmp6 and ip6[40] = 2) or (ip6 and tcp port 80)' ... 10:44:03.689758 IP6 (hlim 240, next-header ICMPv6 (58) payload length: 1240) 2001:470:1:18::3:1280 > fdbf:1d37:bbe0:0:48::35: [bad icmp6 cksum 0xa86c -> 0xbb23!] ICMP6, packet too big, mtu 1280 ... ----------------------------- but not on the interface vmbr2 to which 2a02:a00:f010:3300::113 is connected ----------------------------- ip -6 route get 2a02:a00:f010:3300::113 2a02:a00:f010:3300::113 from :: dev vmbr2 proto kernel src 2a02:a00:f010:3300::fb metric 1024 pref medium ----------------------------- The above tcpdump shows nothing arriving there. Since normal traffic and pings do arrive there and get SNATted correctly, I wonder what keeps these "packet too big" icmps away. testing ipV6v connectivity on https://test-ipv6.com also informs me of this issue: Check your firewall to make sure that ICMPv6 messages are allowed (in particular, Type 2 or Packet Too Big) Am I missing something obvious here? I can't find the reason. There have been similar questions about this in the past, but none of the possible solutions seem to apply in my case. Kind regards, Uwe |
From: Roberto C. S. <ro...@co...> - 2024-03-03 21:32:49
|
On Fri, Mar 01, 2024 at 12:43:24PM +0200, Tuomo Soini wrote: > On Thu, 29 Feb 2024 17:17:15 -0500 > Roberto C. Sánchez <ro...@co...> wrote: > > > The odd thing is that I know I have other helpers working correctly. I > > have AUTOHELPERS=Yes in /etc/shorewall/shorewall.conf and things like > > FTP work as expected. > > See this part of documentation. Nobody should have AUTOHELPERS enabled > any more. I suggest you switch to AUTOHELPERS=No and test again because > you likely have later than 3.5 kernel. > > https://shorewall.org/Helpers.html#idm217 > Thanks for the pointer. That did turn out to be exactly the bit of information I needed. In retrospect, when I was troubleshooting the problem and I looked in macro.SANE at "! $AUTOHELPERS" it should have occurred to me that "AUTOHELPERS=Yes" was actually the source of my problem. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com |
From: Roberto C. S. <ro...@co...> - 2024-03-01 14:21:59
|
On Fri, Mar 01, 2024 at 12:43:24PM +0200, Tuomo Soini wrote: > On Thu, 29 Feb 2024 17:17:15 -0500 > Roberto C. Sánchez <ro...@co...> wrote: > > > The odd thing is that I know I have other helpers working correctly. I > > have AUTOHELPERS=Yes in /etc/shorewall/shorewall.conf and things like > > FTP work as expected. > > See this part of documentation. Nobody should have AUTOHELPERS enabled > any more. I suggest you switch to AUTOHELPERS=No and test again because > you likely have later than 3.5 kernel. > > https://shorewall.org/Helpers.html#idm217 > Wow. I most definitely missed that. Thanks for the pointer to the FAQ. I will certainly update the config and re-test. The configuration on this particular machine originally dates from 2001, so I'm sure I've missed a few things I should have changed on upgrades. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com |
From: Tuomo S. <ti...@fo...> - 2024-03-01 10:43:48
|
On Thu, 29 Feb 2024 17:17:15 -0500 Roberto C. Sánchez <ro...@co...> wrote: > The odd thing is that I know I have other helpers working correctly. I > have AUTOHELPERS=Yes in /etc/shorewall/shorewall.conf and things like > FTP work as expected. See this part of documentation. Nobody should have AUTOHELPERS enabled any more. I suggest you switch to AUTOHELPERS=No and test again because you likely have later than 3.5 kernel. https://shorewall.org/Helpers.html#idm217 -- Tuomo Soini <ti...@fo...> Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> |
From: Roberto C. S. <ro...@co...> - 2024-02-29 22:35:17
|
Hi Everyone, I know I've been away for a while. I recently encountered something strange with macro.SANE. I relocated the scanner in my office (actually a MFP) away from my desk. It sits next to the machine which is my router/gateway (and which runs Shorewall). Setting up network printing (via CUPS) was straighforward. However, setting up scanning to work over the network proved troublesome. In the end I figured out that even with a SANE/ACCEPT rule that somehow connection tracking wasn't working (based on the presence of "reject" messages in syslog where I correlated the DPT with the port on which a saned was spawned and listening). Today I made another attempt on it and it seems that the way the macro is written, the connection tracking helper does not get loaded: ?if ( __CT_TARGET && ! $AUTOHELPERS && __SANE_HELPER ) PARAM - - tcp 6566 { helper=sane } ?else PARAM - - tcp 6566 ?endif When I restart Shorewall, the output of 'lsmod | sane' showed nf_conntrack_sane with a reference count of 0. Xsane on my workstation recognized the scanner and I could hit "Acquire preview" and it would begin the preview scan process, but then hang. Every single time. However, after copying macro.SANE from /usr/share/shorewall to /etc/shorewall and replacing the above with this: PARAM - - tcp 6566 { helper=sane } Then a restart of shorewall and voilà, 'lsmod | sane' showed nf_conntrack_sane with a reference count of 2. After making this change, scanning started to work perfectly. The odd thing is that I know I have other helpers working correctly. I have AUTOHELPERS=Yes in /etc/shorewall/shorewall.conf and things like FTP work as expected. I'm wondering if anyone might have an idea of what is going with this. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com |