# [Solved] Internet Access Issues

## OldTango

I have a Gentoo Server set up as a router and gateway for all devices and printers on the LAN. When when the ISP drops its connection to the modem, all devices loose connection to the internet including the Server as expected. Internally the LAN operates normally only the internet is lost. When the modem re-establishes a connection to the ISP only the server will have assess to the internet. No systems on the LAN have internet access even though they all have valid IP addresses and state they are connected to the internet. It also appears to be affected by the amount of time the ISP drops its connection to the modem. If less than five minutes or so, once the ISP re-establishes a connection all devices of the LAN have internet access, any time longer and internet access from the LAN is lost.

The only way for me to regain internet access from the LAN is to reboot the Server or restart the LAN ether card manually

```
/etc/init.d/net.enp26s0 restart

 * Unmounting network filesystems ...                                                                             [ ok ]

 * Stopping dnsmasq ...

 * start-stop-daemon: no matching processes found                                                                 [ ok ]

 * Bringing down interface enp26s0

 * Bringing up interface enp26s0

 *   192.168.0.1/24 ...                             

 Starting dnsmasq ...                                                                 [ ok ]

 * Mounting network filesystems ...                                                                               [ ok ]

^C
```

When restarting manually the process also hangs and won't exit, without me killing the process. 

This problem started just recently, most likely after some update. Before this issue arose, once the ISP re-established a modem connection all devices on the LAN regained internet access within a few seconds.

/etc/conf.d/net

```
# Prefer ifconfig over iproute2

#modules="ifconfig"

config_enp24s0="dhcp"

config_enp26s0="192.168.0.1/24"
```

/etc/sysctl.conf

```
net.ipv4.ip_forward = 1

net.ipv4.ip_dynaddr = 1

net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.all.rp_filter = 1
```

TIA Tango.....  :Confused: Last edited by OldTango on Fri Sep 30, 2022 10:46 pm; edited 1 time in total

----------

## pietinger

 *OldTango wrote:*   

> [...] When the modem re-establishes a connection to the ISP only the server will have assess to the internet. No systems on the LAN have internet access even though they all have valid IP addresses and state they are connected to the internet. [...] If less than five minutes or so, once the ISP re-establishes a connection all devices of the LAN have internet access, any time longer and internet access from the LAN is lost.

 

Last sentence sounds like a DNS problem ... Have you proofed if a ping 8.8.8.8 from a LAN Client work ?

If yes, we should ask why name resolving is a problem (I see dnsmasq ...).

If no: Do you have something in you systemlog (dmesg) of your Server ?

----------

## Hu

Does the gateway receive the same IP address afterward as it did before?  If no, do you have any firewall rules that assume the answer was yes?

----------

## OldTango

Sorry but the term gateway confuses me somewhat.

The server has 2 nic cards. The WAN nic-card (enp24s0) is connected to the ISP's modem and configured for dhcp. The LAN nic-card (enp26s0) is connected to a gigabit switch and is hard coded to always receive the IP of 192.168.0.1

I do use dnsmasq as an internal dhcp server and this issue may have started with a recent upgrade of dnsmasq.

/etc/dnsmasq.conf

```
#

If you want dnsmasq to listen for DHCP and DNS requests only on

# specified interfaces (and the loopback) give the name of the

# interface (eg eth0) here.

# Repeat the line for more than one interface.

interface=enp26s0

# Uncomment this to enable the integrated DHCP server, you need

# to supply the range of addresses available for lease and optionally

# a lease time. If you have more than one network, you will need to

# repeat this for each network on which you want to supply DHCP

# service.

#dhcp-range=192.168.0.50,192.168.0.150,12h

# This is an example of a DHCP range where the netmask is given. This

# is needed for networks we reach the dnsmasq DHCP server via a relay

# agent. If you don't know what a DHCP relay agent is, you probably

# don't need to worry about this.

dhcp-range=enp26s0,192.168.0.100,192.168.0.250,72h

# Always allocate the host with Ethernet address 11:22:33:44:55:66

# The IP address 192.168.0.60

#dhcp-host=11:22:33:44:55:66,192.168.0.60

#HP Printers

#dhcp-host=00:21:5a:9f:a6:91,192.168.0.110

dhcp-host=34:64:a9:66:b5:ce,192.168.0.130

#Ubiquiti WAP

dhcp-host=04:18:D6:80:5B:3A,192.168.0.107

#Roku

#dhcp-host=B0:A7:37:0C:4D:88,192.168.0.61
```

Dmesg is reviling as it is showing a segfault for dnsmasq once the ISP has gone down for an extended period of time. Here you can see I logged-in VIA SSH to restart the LAN nic and regain internet access.

dmesg

```

[398704.013218] igb 0000:18:00.0 enp24s0: igb: enp24s0 NIC Link is Down

[398704.108585] dnsmasq[10478]: segfault at 56180143b79d ip 00005617ffc03ad8 sp 00007ffe05f9aae0 error 4 in dnsmasq[5617ffbc6000+3f000]

[398704.108591] Code: ff ff 48 83 7c 24 08 00 48 8b 44 24 08 7f 1b e9 d3 fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 49 ff c7 48 ff c8 74 07 <41> 80 7f ff 2e 75 f1 48 89 44 24 08 e9 b7 fd ff ff 0f 1f 80 00 00

[398721.291647] igb 0000:18:00.0 enp24s0: igb: enp24s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

[398728.112222] igb 0000:18:00.0 enp24s0: igb: enp24s0 NIC Link is Down

[398731.055596] igb 0000:18:00.0 enp24s0: igb: enp24s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

[419792.419929] elogind-daemon[2686]: New session 11 of user michael.

[419813.899529] e1000e: enp26s0 NIC Link is Down

[419814.017726] IPv6: ADDRCONF(NETDEV_UP): enp26s0: link is not ready

[419817.522456] e1000e: enp26s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

[419817.522786] IPv6: ADDRCONF(NETDEV_CHANGE): enp26s0: link becomes ready

[420171.281541] elogind-daemon[2686]: Removed session 11.
```

A latter ISP drop that lasted less than five minutes caused no issues.

```

[420772.851067] igb 0000:18:00.0 enp24s0: igb: enp24s0 NIC Link is Down

[420790.056478] igb 0000:18:00.0 enp24s0: igb: enp24s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

[420796.876316] igb 0000:18:00.0 enp24s0: igb: enp24s0 NIC Link is Down

[420799.849744] igb 0000:18:00.0 enp24s0: igb: enp24s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

[451361.393138] elogind-daemon[2686]: New session 12 of user michael.
```

I use a firewall script (iptables) which saves the firewall state after I open or close external ports as needed.

```
#!/bin/bash

#File Name = firewall-rules.sh

#First we flush our current rules:

iptables -F

iptables -t nat -F

#default policies to handle unmatched traffic:

iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT

iptables -P FORWARD DROP

#Export our NIC's:

export LAN=enp26s0

export WAN=enp24s0

#Lock our services so they only work from the LAN:

iptables -I INPUT 1 -i ${LAN} -j ACCEPT

iptables -I INPUT 1 -i lo -j ACCEPT

iptables -A INPUT -p UDP --dport bootps ! -i ${LAN} -j REJECT

iptables -A INPUT -p UDP --dport domain ! -i ${LAN} -j REJECT

#Drop all ping requests on system:

iptables -I INPUT -p icmp --icmp-type echo-request -i ${WAN} -j DROP

#Allow access to our ssh and http server from the WAN:

#iptables -A INPUT -p TCP --dport 22 -i ${WAN} -j ACCEPT

#iptables -A INPUT -p TCP --dport 80 -i ${WAN} -j ACCEPT

#Access to the Quake3 Server ports:

#iptables -A INPUT -p udp -m state --state NEW,ESTABLISHED,RELATED --dport 27960:27965 -i ${WAN} -j ACCEPT

#iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED,RELATED --dport 27960:27965 -i ${WAN} -j ACCEPT

#Drop TCP / UDP packets to privileged ports:

iptables -A INPUT -p TCP ! -i ${LAN} -d 0/0 --dport 0:5000 -j DROP

iptables -A INPUT -p UDP ! -i ${LAN} -d 0/0 --dport 0:5000 -j DROP

#Add the rules for NAT:

iptables -I FORWARD -i ${LAN} -d 192.168.0.0/255.255.0.0 -j DROP

iptables -A FORWARD -i ${LAN} -s 192.168.0.0/255.255.0.0 -j ACCEPT

iptables -A FORWARD -i ${WAN} -d 192.168.0.0/255.255.0.0 -j ACCEPT

iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE

#Tell the kernel that ip forwarding is OK:

echo 1 > /proc/sys/net/ipv4/ip_forward

for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done

#Save our rules:

/etc/init.d/iptables save
```

There appears to be an issue with dnsmasq segfaulting, but only after a prolonged ISP outage and it started with the recent dnsmasq update.

TIA Tango.....  :Confused: 

----------

## pietinger

First of all: Yes, I think there is a problem with dnsmasq (but I am not a specialist for it). Surely a dnsmasq expert can help.

Your firewall-rules seems to be old, because you could work more with "stateful inspection" (it is more secure than enabling all input-ports greater than 5000). I recommend also to work with logging to see if something happened. Also working with -I (for insert) is not necessary. You should also ask with "iptables -L -v -n" to see quantity of packets for each rule. I would recommend to rewrite your rules like this:

```
First we flush our current rules:

iptables -F

iptables -t nat -F

#default policies to handle unmatched traffic; SET INPUT also to DROP:

iptables -P INPUT DROP

iptables -P OUTPUT ACCEPT

iptables -P FORWARD DROP

#Export our NIC's:

export LAN=enp26s0

export WAN=enp24s0

# Allow all internal traffic on loopback (a second rule with "-o lo" is not necessary because you allow all OUTPUT traffic with default policy)

iptables -A INPUT -i lo -j ACCEPT

# Allow all packets which are answers to an existing session (=stateful inspection)

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow all incoming traffic from LAN:

iptables -A INPUT -i ${LAN} -j ACCEPT

# Not necessary anymore because of default policy DROP

#iptables -A INPUT -p UDP --dport bootps ! -i ${LAN} -j REJECT

#iptables -A INPUT -p UDP --dport domain ! -i ${LAN} -j REJECT

#Allow access to our ssh and http server from the WAN:

#iptables -A INPUT -p TCP --dport 22 -i ${WAN} -j ACCEPT

#iptables -A INPUT -p TCP --dport 80 -i ${WAN} -j ACCEPT

#Access to the Quake3 Server ports:

#iptables -A INPUT -p udp -m state --state NEW --dport 27960:27965 -i ${WAN} -j ACCEPT

#iptables -A INPUT -p tcp -m state --state NEW --dport 27960:27965 -i ${WAN} -j ACCEPT

# DANGEROUS - and not necessary anymore because of new stateful inspection

#Drop TCP / UDP packets to privileged ports:

#iptables -A INPUT -p TCP ! -i ${LAN} -d 0/0 --dport 0:5000 -j DROP

#iptables -A INPUT -p UDP ! -i ${LAN} -d 0/0 --dport 0:5000 -j DROP

# Drop all ping requests from WAN to system without logging:

iptables -A INPUT -p icmp --icmp-type echo-request -i ${WAN} -j DROP

# log all other packets

iptables -A INPUT -j LOG --log-prefix "DROP IN "

# Allow routing from LAN to WAN

iptables -A FORWARD -i ${LAN} -s 192.168.0.0/255.255.0.0 -j ACCEPT

# DANGEROUS - and not necessary anymore because of stateful inspection

# iptables -A FORWARD -i ${WAN} -d 192.168.0.0/255.255.0.0 -j ACCEPT

# log all other packets

iptables -A FORWARD -j LOG --log-prefix "DROP FWD "

#Add rule for NAT:

iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE
```

----------

## Hu

 *OldTango wrote:*   

> Sorry but the term gateway confuses me somewhat.

 The computer where you run dnsmasq is your gateway, which sits between the LAN and the Internet.

You originally wrote that the LAN systems lose access to the Internet, which would point to a firewall problem.  More recently, you wrote that dnsmasq crashed, which would bring down your DNS service, but would not affect IP connectivity.  Please describe exactly what symptoms led you to say that the LAN systems lost access to the Internet.  It seems more likely that they have Internet access, but no name resolution, which would make some things (like web browsers) nearly useless, but have little effect on applications that are configured with specific target IP addresses. *OldTango wrote:*   

> I use a firewall script (iptables) which saves the firewall state after I open or close external ports as needed.
> 
> ```
> #!/bin/bash
> ```
> ...

 You are not the first person I have seen use a bash script for a firewall, and as I have told every person before you, this is dangerous and wrong, because it is non-atomic.  To be safe, you need to load your rules using iptables-restore, which is what Gentoo's initscript can do for you.  With the way your script is written, if any step fails, the later ones will run anyway, and you end up with some hybrid between the old state and the intended state.  This hybrid may or may not satisfy your security and functionality requirements. *OldTango wrote:*   

> 
> 
> ```
> #Export our NIC's:
> 
> ...

 export is not needed for script-local variables. *OldTango wrote:*   

> 
> 
> ```
> iptables -A INPUT -p UDP --dport bootps ! -i ${LAN} -j REJECT
> 
> ...

 Why REJECT instead of DROP? *OldTango wrote:*   

> 
> 
> ```
> #Drop TCP / UDP packets to privileged ports:
> 
> ...

 Why allow traffic to unprivileged ports on the gateway?  Also, note that traditionally "privileged" refers to the ports that only CAP_NET_ADMIN can open (ports below 1024). *OldTango wrote:*   

> 
> 
> ```
> iptables -A FORWARD -i ${WAN} -d 192.168.0.0/255.255.0.0 -j ACCEPT
> ```
> ...

 As pietinger said, use stateful inspection instead of this.

----------

## pietinger

 *Hu wrote:*   

> You are not the first person I have seen use a bash script for a firewall, and as I have told every person before you, this is dangerous and wrong, because it is non-atomic.  To be safe, you need to load your rules using iptables-restore, which is what Gentoo's initscript can do for you.  With the way your script is written, if any step fails, the later ones will run anyway, and you end up with some hybrid between the old state and the intended state.  This hybrid may or may not satisfy your security and functionality requirements.

 

Hu,

it is true that /etc/init.d/iptables should do the job of loading all rules at boot-time ... BUT ... using a script for an initial setting (or later, if you want to change your configuration) is NOT dangerous IF you work with a default policy of "DROP", because if your script would abort int the middle of it, "only" all rules which do an "ACCEPT" would be missing. You must have a very, very complex configuration to become dangerous when working with a script - not in these easy cases.

Yes, you are right with all comments to his script (e.g. EXPORT) - I have only focused on rules.

@OldTango:

I have tried (with my poor english) to explain "stateful inspection" here: https://forums.gentoo.org/viewtopic-p-8465650.html#8465650

(You will find also my script for a personal firewall in the first post of this thread)

----------

## Hu

The problem is that the script may not abort in the middle.  It is also missing set -eu, so any failed iptables commands will just be ignored and later commands will still execute.  If the script at least aborted on the first error, it would be easier to reason about whether there are specific failure modes that will leave the firewall in a dangerous state.  I generally recommend that people maintain their rules as a file that can be consumed by iptables-restore, so that the rules can be loaded atomically.  The only downside is that there is no native preprocessor for this, so variable substitutions would require a helper script.

----------

## pietinger

 *Hu wrote:*   

> [...] I generally recommend that people maintain their rules as a file that can be consumed by iptables-restore, so that the rules can be loaded atomically.  The only downside is that there is no native preprocessor for this, so variable substitutions would require a helper script.

 

This is a good recommendation and I think all experienced users will do so. My goal is to help beginners with an easy to use solution. Here it is "only" necessary to have three lines (or two if you want allow ALL outgoing traffic) WITHOUT a typo in the script:

```
iptables -P INPUT       DROP

iptables -P OUTPUT      DROP

iptables -P FORWARD     DROP
```

If you have a typo here - YES, you have a problem - these lines MUST be correct. Please keep in mind: I use it only for inital setting, I ALSO check with "iptables -L -v -n" immediately afterwards (and if I want to change/add a rule WITH an immediately check).

----------

## Hu

I have seen many users who start with a script like this, and then declare it to be their long-term solution for loading rules at every boot.  Typos are not the only threat.  Some of these rulesets also depend on specific optional kernel features being enabled; if the script runs on a kernel without that feature, that one line fails, and the others run anyway, even though the user made no errors in writing the script.

----------

## pietinger

 *Hu wrote:*   

> I have seen many users who start with a script like this, and then declare it to be their long-term solution for loading rules at every boot.  Typos are not the only threat.  Some of these rulesets also depend on specific optional kernel features being enabled; if the script runs on a kernel without that feature, that one line fails, and the others run anyway, even though the user made no errors in writing the script.

 

YES ! Let me quote myself from my other thread:

 *Quote:*   

> Today we have our own script for saving and restoring the settings: "/etc/init.d/iptables". Use only this one !

 

----------

## OldTango

First: I would like to thank you Hu and pietinger for all your help and advise.

Second: I know little to nothing about iptables and even less about bash.

Some history:

My SERVER is a stand alone Gentoo based system that acts as a router and firewall for my LAN. Its also a local FTP, PRINT and SYNC server and it runs a couple of small CRON jobs weekly. It was first built and Gentoo installed in 2004 and while the hardware has been replaced several times over the years, it has only seen one fresh Gentoo install when I switched to using UEFI. Its currently running a series 4.6 UEFI STUB-KERNEL.

I started with the Gentoo Wiki's Home Router Guide years ago, but every time I needed to open or close certain ports I found myself manually imputing all the rules, so I searched for scripting methods to make it easier. The script I created and posted provided all my needs at the time and as far as I can tell works as intended. The only way I know to test the firewall is with ShieldsUP. I know the script is not perfect and quite old.

I use dnsmasq because a few devices on my LAN need fixed/assigned IP addresses and their IP's have to be maintained across reboots, system outages and hardware problems. While dnsmasq might be overkill it worked well until the last update. I am still searching for this issue. Is there a better way of doing this.

 *Hu wrote:*   

> You originally wrote that the LAN systems lose access to the Internet, which would point to a firewall problem.  More recently, you wrote that dnsmasq crashed, which would bring down your DNS service, but would not affect IP connectivity.  Please describe exactly what symptoms led you to say that the LAN systems lost access to the Internet.  It seems more likely that they have Internet access, but no name resolution, which would make some things (like web browsers) nearly useless, but have little effect on applications that are configured with specific target IP addresses.

 I'll try my best. When the ISP drops its connection to the modem, the WAN=enp24s0 ether link goes down and no devices on the network have internet access.

When the ISP reconnects to the modem (if it reconnects within five minutes or less) the WAN=enp24s0 ether link goes back up and all is well again.

However IF the connection to the ISP is down for an extended period of time, dnsmasq will segfault. Why this is happening I have no idea at this point. Once dnsmasq has segfaulted, and the ISP connection to the modem is re-established the WAN=enp24s0 ether link goes back up. At this juncture no device from the LAN can connect to or browse the internet, except the the SERVER.

 *Hu wrote:*   

> I generally recommend that people maintain their rules as a file that can be consumed by iptables-restore, so that the rules can be loaded atomically.

 This sounds like great advise, but how would I go about this process and what rules would I need to write? I no longer have the need to open or close any ports. I want my SERVER to act as a router, be invisible from the outside world and to DROP all ping requests and still allow all devices on the LAN (inside the network) to have full internet access.

I am open to any and all help you are willing to offer. I need to stick with iptables for now as my kernels are not configured for nftables.

TIA Tango.....  :Confused: 

----------

## Hu

 *OldTango wrote:*   

> it has only seen one fresh Gentoo install when I switched to using UEFI.

 That probably was not necessary.  UEFI boot vs BIOS boot is similar enough that you only needed to adjust the bootloader and kernel.  You could have kept all the user programs. *OldTango wrote:*   

> Its currently running a series 4.6 UEFI STUB-KERNEL.

 That seems like an odd choice.  4.6.x was not a Long Term Stable series, I think.  Even if it was, it looks like 4.9.x is the oldest LTS still receiving updates. *OldTango wrote:*   

> However IF the connection to the ISP is down for an extended period of time, dnsmasq will segfault.

 Can you force this failure by physically disconnecting the modem from the cable upstream, and leaving it that way for the required amount of time?  If so, that would make this much easier to debug. *OldTango wrote:*   

> At this juncture no device from the LAN can connect to or browse the internet, except the the SERVER.

 I still find this unlikely, so I will restate and clarify my earlier request.  Please give us specific commands that you ran that did not produce the good result and the error messages that they produced instead.  I strongly suspect that IP connectivity is fine, and that your issue is that the LAN-side computers are unable to resolve names because they want the crashed dnsmasq process to answer their name service queries.  When you are in the bad state, run: ping -c4 www.gentoo.org; ping -c4 146.75.106.137.  The latter is an address that www.gentoo.org resolves to, so you should get the same results for both commands.  I expect that the first will fail and the second will succeed. *OldTango wrote:*   

> This sounds like great advise, but how would I go about this process and what rules would I need to write?

 Set aside your script.  Take the rules that the Gentoo init script writes to /var/lib/iptables/rules-save.  When you need to make a change, change those, and use iptables-restore < /path/to/rules/file to load it.  You may wish to maintain your hand-edited copy in a separate location, and/or place it in source control, to avoid losing your only good copy if you make a mistake.

----------

## OldTango

@Hu

True I could have cloned my drives and made the required changes, but there was a lot of left over cruft from years of changing DE's and some bad or stale symlinks. I felt it best to start clean.

My mistake my current kernel is 4.19.86-gentoo. I upgraded to it from a 4.6 series kernel.

Yes, great idea, I will force dnsmasq to segfault tomorrow when no one else needs the network. At that time I will do the ping tests from a couple of systems on the LAN. I have a working theory of what might be causing the crash and will test that as well. 

Are you saying I should actually edit the /var/lib/iptables/rules-save file, or create a rules file and save it somewhere.

My current "/var/lib/iptables/rules-save" file which was created by my script I'm sure is very confusing to read.

```

 Generated by iptables-save v1.8.7 on Wed Sep 21 11:09:11 2022

*nat

:PREROUTING ACCEPT [2550223:438552205]

:INPUT ACCEPT [386129:38713920]

:OUTPUT ACCEPT [161988:11390202]

:POSTROUTING ACCEPT [301:86932]

[369660:37660284] -A POSTROUTING -o enp24s0 -j MASQUERADE

COMMIT

# Completed on Wed Sep 21 11:09:11 2022

# Generated by iptables-save v1.8.7 on Wed Sep 21 11:09:11 2022

*mangle

:PREROUTING ACCEPT [13993158510:18655365030180]

:INPUT ACCEPT [133021866:24456554513]

:FORWARD ACCEPT [13777940931:18626823273144]

:OUTPUT ACCEPT [46442058:16192160257]

:POSTROUTING ACCEPT [13824321780:18643000960059]

COMMIT

# Completed on Wed Sep 21 11:09:11 2022

# Generated by iptables-save v1.8.7 on Wed Sep 21 11:09:11 2022

*filter

:INPUT ACCEPT [444028:63023136]

:FORWARD DROP [1:40]

:OUTPUT ACCEPT [746423:178352456]

[6369:494430] -A INPUT -i enp24s0 -p icmp -m icmp --icmp-type 8 -j DROP

[1565:161960] -A INPUT -i lo -j ACCEPT

[724104:57762209] -A INPUT -i enp26s0 -j ACCEPT

[0:0] -A INPUT ! -i enp26s0 -p udp -m udp --dport 67 -j REJECT --reject-with icmp-port-unreachable

[204:13315] -A INPUT ! -i enp26s0 -p udp -m udp --dport 53 -j REJECT --reject-with icmp-port-unreachable

[34581:1436528] -A INPUT ! -i enp26s0 -p tcp -m tcp --dport 0:5000 -j DROP

[1859378:367919730] -A INPUT ! -i enp26s0 -p udp -m udp --dport 0:5000 -j DROP

[0:0] -A FORWARD -d 192.168.0.0/16 -i enp26s0 -j DROP

[72844015:6026471930] -A FORWARD -s 192.168.0.0/16 -i enp26s0 -j ACCEPT

[102847439:267104261320] -A FORWARD -d 192.168.0.0/16 -i enp24s0 -j ACCEPT

COMMIT

# Completed on Wed Sep 21 11:09:11 2022
```

TIA Tango.....  :Confused: 

----------

## Hu

I would suggest copying the file elsewhere and modifying that copy, so that you have a clean version if your edits render the file ill-formed.  Depending on your proficiency with the rules language, and the frequency with which you make changes, you may want to place it under source control so that you can always return to any prior version.

I work with that format as my preferred form, so it is not confusing in my opinion.  :Smile: 

----------

## OldTango

 *Hu wrote:*   

> Can you force this failure by physically disconnecting the modem from the cable upstream, and leaving it that way for the required amount of time?  If so, that would make this much easier to debug.

 Did this today.

```

610491.966721] igb 0000:18:00.0 enp24s0: igb: enp24s0 NIC Link is Down <-----FORCE SHUTDOWN & WAIT

dnsmasq[4466]: segfault at 564ee6851602 ip 0000564ee65f2ad8 sp 00007ffcd7a6f170 error 4 in dnsmasq[564ee65b5000+3f000]

[610517.441236] Code: ff ff 48 83 7c 24 08 00 48 8b 44 24 08 7f 1b e9 d3 fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 49 ff c7 48 ff c8 74 07 <41> 80 7f ff 2e 75 f1 48 89 44 24 08 e9 b7 fd ff ff 0f 1f 80 00 00

[611396.879260] igb 0000:18:00.0 enp24s0: igb: enp24s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX <-----BRING IT BACK ONLINE

michael@SuperTux ~ $ ping -c4 www.gentoo.org <---- FROM THE LAN

ping: www.gentoo.org: Temporary failure in name resolution

michael@SuperTux ~ $ ping -c4 146.75.106.137

PING 146.75.106.137 (146.75.106.137) 56(84) bytes of data.

64 bytes from 146.75.106.137: icmp_seq=1 ttl=52 time=26.0 ms

64 bytes from 146.75.106.137: icmp_seq=2 ttl=52 time=25.6 ms

64 bytes from 146.75.106.137: icmp_seq=3 ttl=52 time=29.0 ms

64 bytes from 146.75.106.137: icmp_seq=4 ttl=52 time=29.5 ms

--- 146.75.106.137 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3003ms

rtt min/avg/max/mdev = 25.550/27.504/29.458/1.739 ms

michael@SuperTux ~ $ 

MasterTux /home/michael # /etc/init.d/dnsmasq restart <----- FROM SERVER VIA SSH

 * Stopping dnsmasq ...

 * start-stop-daemon: no matching processes found <----- FROM SEGFAULT OF DNSMASQ                                                                [ ok ]

 * Starting dnsmasq ... 

michael@SuperTux ~ $ ping -c4 www.gentoo.org <----- FROM THE LAN AFTER RESTART OF DNSMASQ

PING dualstack.k.sni.global.fastly.net (151.101.70.137) 56(84) bytes of data.

64 bytes from 151.101.70.137 (151.101.70.137): icmp_seq=1 ttl=55 time=16.4 ms

64 bytes from 151.101.70.137 (151.101.70.137): icmp_seq=2 ttl=55 time=12.6 ms

64 bytes from 151.101.70.137 (151.101.70.137): icmp_seq=3 ttl=55 time=14.1 ms

64 bytes from 151.101.70.137 (151.101.70.137): icmp_seq=4 ttl=55 time=15.5 ms

--- dualstack.k.sni.global.fastly.net ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3003ms

rtt min/avg/max/mdev = 12.571/14.630/16.378/1.446 ms
```

All of this is caused by dnsmasq segfaulting.

TIA Tango.....  :Confused: 

----------

## Hu

That ping output from the LAN confirms my suspicion.  Your LAN machines still have Internet connectivity, but with dnsmasq down, they have no name service, so they must do everything by IP address.

----------

## pietinger

OldTango,

as I wrote before, I am not a dnsmasq expert, but I can say a segfault is a serious problem. You said you have the problem since last update of dnsmasq. So, how to find the reason ?

Let me say it very clear: It will not be easy. It could be a combination of everything, e.g. your actual kernel version is 4.19.86 ! You know actual stable version of 4.19-series is: 4.19.259 ?

Do you have actual versions of "gcc" and "glibc" ? Do you have linux-headers-4.19-r1 ? If no, do a world-update. If yes, do a world-update and update your kernel; then check if your problem is solved. (=update your kernel in every case  :Wink:  ) 

Your firewall we can do later; it is not urgent, but if you want you can do a little bit:

1. Check if you have start-stop-script "iptables" in runlevel "default" with "rc-update". If not, do "rc-update add iptables default" (and if you start your script at any other position, remove it).

2. You have forwarding enabled in /etc/sysctl.conf - GOOD ! -> so there is no need to do it in your script again.

3. Until you are more initimate with firewalling you can do ONCE this script - @Hu will shout to me - WITH an immediate check of it WITH "iptables -L -v -n" (watch also all numbers in column "pkts"):

```
#!/bin/bash

set -eu

# Define our NIC's:

LAN=enp26s0

WAN=enp24s0

# First we flush our current rules:

iptables -F

iptables -t nat -F

iptables -X

# default policies to handle unmatched traffic; SET INPUT also to DROP:

iptables -P INPUT DROP

iptables -P OUTPUT ACCEPT

iptables -P FORWARD DROP

### INPUT ###

# Allow all internal traffic on loopback (a second rule with "-o lo" is not necessary because you allow all OUTPUT traffic with default policy)

iptables -A INPUT -i lo -j ACCEPT

# Allow all packets which are answers to an existing session (=stateful inspection)

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow all incoming traffic from LAN:

iptables -A INPUT -i ${LAN} -j ACCEPT

# ----- Not used at the moment -----

#Allow access to our ssh and http server from the WAN:

#iptables -A INPUT -p TCP --dport 22 -i ${WAN} -j ACCEPT

#iptables -A INPUT -p TCP --dport 80 -i ${WAN} -j ACCEPT

#Access to the Quake3 Server ports:

#iptables -A INPUT -p udp -m state --state NEW --dport 27960:27965 -i ${WAN} -j ACCEPT

#iptables -A INPUT -p tcp -m state --state NEW --dport 27960:27965 -i ${WAN} -j ACCEPT

# ----------------------------------

# Drop all ping requests from WAN to system without logging:

iptables -A INPUT -p icmp --icmp-type echo-request -i ${WAN} -j DROP

# Here you can/should add more rules for dropping some packets which shall not be loged; but first watch your /var/log/messages

# log all other packets

iptables -A INPUT -j LOG --log-prefix "DROP IN "

### FORWARD ###

# Allow routing from LAN to WAN

iptables -A FORWARD -i ${LAN} -s 192.168.0.0/16 -j ACCEPT

# log all other packets

iptables -A FORWARD -j LOG --log-prefix "DROP FWD "

### NAT ###

# Add rule for NAT:

iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE
```

(/etc/init.d/iptables saves all rules at every shutdown; but first time after a new configuration is set you should do it once manually with "/etc/init.d/iptables save").

After this initial configuration you can look into /var/lib/iptables/rules-save and go the way @Hu has already recommended !

----------

## OldTango

 *pietinger wrote:*   

> OldTango, as I wrote before, I am not a dnsmasq expert, but I can say a segfault is a serious problem. You said you have the problem since last update of dnsmasq. So, how to find the reason ?

  While I am not 100% certain, I believe I have chased it down to a bug introduced into the dnsmasq-2.86 series, and I haven't been able to verify the patch is applied in the gentoo ebuild. I will fetch the patch from upstream and apply it myself, then test to see if it solves the problem before I file a BUG report in Gentoo. The patch in question is Here and describes my exact observations of what is occurring.

 *pietinger wrote:*   

> Let me say it very clear: It will not be easy. It could be a combination of everything, e.g. your actual kernel version is 4.19.86 ! You know actual stable version of 4.19-series is: 4.19.259 ?

 True, but the 4.19 series is LTS and 4.19.86 was stable when I upgraded to it. I will be moving to a 5 series LTS in a couple of months or so when I have the time to build and test one.

 *pietinger wrote:*   

> Do you have actual versions of "gcc" and "glibc" ? Do you have linux-headers-4.19-r1 ? If no, do a world-update. If yes, do a world-update and update your kernel; then check if your problem is solved. (=update your kernel in every case  )

 Yes on all of the above and I keep all my Gentoo systems up to date weekly and just ran an update yesterday using the command

```
emerge -avuND --exclude sys-kernel/* --with-bdeps=y @world
```

 *pietinger wrote:*   

> Your firewall we can do later; it is not urgent, but if you want you can do a little bit:
> 
> 1. Check if you have start-stop-script "iptables" in runlevel "default" with "rc-update". If not, do "rc-update add iptables default" (and if you start your script at any other position, remove it).
> 
> 2. You have forwarding enabled in /etc/sysctl.conf - GOOD ! -> so there is no need to do it in your script again.
> ...

 I have used a script to set/reset the firewall only after I have made changes and then just let the init.d process continue from there.

```
michael@MasterTux ~ $ rc-update -s

iptables |      default
```

So yes, I would like to use a script to move to a state-full firewall after which I will invest some time learning Hu's method.

I will use your suggested script changes tomorrow then check/test the results.

TIA Tango.....  :Smile: 

----------

## pietinger

Great, you found the reason of the dnsmasq problem  :Smile: 

Yes, I know 4.19 is LTS - therefore I have recommended 4.19.259 because this is latest (Gentoo-) stable of 4.19. Actual is 4.19.260 at the moment. But if you want to change to 5.15 in some month you could also wait until 6.1 because this will be the next LTS kernel.

Let me say a word to your firewall - or to firewalls at all:

Your actual rules - and even what I have given you - is not as secure as you might think ... because:

You do filtering only for incoming traffic and not for outgoing traffic (OUTPUT + FORWARD from LAN). This allows "Hole punching" ( https://en.wikipedia.org/wiki/Hole_punching_(networking) ) ... with endeffect an evil programm - or just your webbrowser when hitting an evil page - is able to connect to bad servers. So, yes your actual firewall rules are better than nothing, but dont trust too much in it. As I said in my other post: Sometimes a firewall can not protect you - it can only warn you there "was something". If you want more security you must use proxies and filter all outgoing traffic and do (automated) checking of syslog.

(This I had to say as a paronoid man for security  :Wink:  )

----------

## NeddySeagoon

I like Shorewall but see the warning in the opening paragraph.

----------

## OldTango

 *NeddySeagoon wrote:*   

> I like Shorewall but see the warning in the opening paragraph.

 I used Shorewall back in the old Mandrake days, before I found Gentoo and it was huge even then. It took me 2 weeks to figure it out and I wanted to beat myself silly in the end.....  :Laughing: . I find iptables a little eaiser to use even though I still lack any real proficiency with it.

Best Tango.....  :Smile: 

----------

## pietinger

 *NeddySeagoon wrote:*   

> I like Shorewall but see the warning in the opening paragraph.

 

Neddy, you wrote in this article: "There are lots of logs in /var/log. dmesg will be flooded with DROPs due to all the logging."

THIS is the reason I dont like any software (e.g. also UFW) doing my firewall configuration. LOGGING is important - YES ! But not every silly ping request from internet (you know how often we have a port scan). The usual method for dealing with this is:

I. Policy is DROP

II. Accept all what you need:

  1. If you allow connects to specific server (e.g. mail to your mail-provider) this is no problem.

  2. If you must allow a complete protocol to unspecified servers (like HTTPS) you have two choices:

     2a. Route this traffic to a proxy and let the proxy log all (AND of course ALLOW only Proxy for handling this protocol), OR

     2b. LOG every connect (as a "Allow XXX") and do an automated Check of your Logfile

III. Now DROP everything which is harmless and would only fill your Log, e.g. all ports Windows uses, IGMP from router, all ICMP (or only ICMP Echo request)

IV. Log now only left free packets with LOG ALL

V. Because of our policy no extra DROP rule is necessary.

I know UFW cannot handle this. If shorewall is able to handle this correct, I dont know. IMHO making all firewall rules with nftables or iptables is easier than with a monster like shorewall. And yes, in big environments (with more than 3 or 4 ports) you have to look to PERFORMANCE also. You cannot optimize with Chains if you dont do it by yourself ...

How important filtering of outgoing traffic is, you can see here (dont mind my german; look only to my dmesg):

https://forums.gentoo.org/viewtopic-p-8669187.html#8669187

(It was an evil webpage when I surved with active Javascript)

----------

## OldTango

 *pietinger wrote:*   

> Neddy, you wrote in this article: "There are lots of logs in /var/log. dmesg will be flooded with DROPs due to all the logging."

 That was one of my complaint years ago. Massive log files.

Best Tango.....  :Smile: 

----------

## OldTango

 *pietinger wrote:*   

> OldTango,(/etc/init.d/iptables saves all rules at every shutdown; but first time after a new configuration is set you should do it once manually with "/etc/init.d/iptables save").
> 
> After this initial configuration you can look into /var/lib/iptables/rules-save and go the way @Hu has already recommended !

 I took your script suggestions and ran them, but discovered I have a logging problem due to a missing kernel module.

```
Warning: Extension LOG revision 0 not supported, missing kernel module?

iptables: No chain/target/match by that name.
```

So I had to comment out the logging for now until I can solve that issue. Looks like I might be moving to a newer kernel very soon.

With your suggestions, iptables -L -v -n produces

```
 

Chain INPUT (policy DROP 863 packets, 126K bytes)

 pkts bytes target     prot opt in     out     source               destination         

    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           

   41  5066 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

  110  9227 ACCEPT     all  --  enp26s0 *       0.0.0.0/0            0.0.0.0/0           

   10   280 DROP       icmp --  enp24s0 *       0.0.0.0/0            0.0.0.0/0            icmptype 8

Chain FORWARD (policy DROP 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination         

32310 8143K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

  100 28042 ACCEPT     all  --  enp26s0 *       192.168.0.0/16       0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 139 packets, 15633 bytes)

 pkts bytes target     prot opt in     out     source               destination
```

and the firewall appears to preform well enough for now.

I have applied a patch to dnsmasq-2.86-r1 and tested to verify it did the job, which it did. So I filed a BUG report to Gentoo and submitted the patch #873700, so I will be marking this topic as solved and will start a new topic about the firewall in a day or so. I really appreciate your and Hu's assistance and input greatly.

Thanks To all!

Best Tango.....  :Smile: 

----------

## pietinger

OldTango,

it depends on your firewall rules which kernel modules you need. I dont know all of them and therefore I recommend (and did myself) to enable all as <M> in both submenus:

```
[*] Networking support  --->

    Networking options  --->

        [*] Network packet filtering framework (Netfilter)  --->

            [*]   Advanced netfilter configuration

                  Core Netfilter Configuration  --->

                  IP: Netfilter Configuration  --->
```

Then I run my script and after this I look into "lsmod" which have been loaded.

Because I want/have a monolithic kernel I set all used as <*> static into my kernel and threw out all unused. But you can let them as <M>odule if you want to enlarge your rules.

Many regards,

Peter

P.S.: Your rules looking good   :Very Happy: 

----------

