@Gertjan Reboot did not help. Restored the working configuration from the backup. It didn’t help either. And today, the same thing happened with LAN. Everyone lost access to the Internet.

I've found the solution, that @ierdelyi found in 2018. https://forum.netgate.com/topic/105000/ipsec-outbound-traffic-being-blocked-on-ipsec-interface/29 With a stateless rule at the GRE interface that allows all wanted traffic it works. Kind regards, Mathias

Ok I'm trying something new and maybe it will work. I only want to schedule 3 computers out of about 30 ip addresses. I created a rule just for those IP addresses and set the schedule to on. Then the gateway was my pia gateway. Reset all the states and firewall table. If this works then it's the easiest way and I'll just stick to this.. One rule with everything combined. Sorry for this basic stuff.. I'm pretty new to firewall rules.

@Sessa45 said in Firewall has rebooted without any strange log entry: @fireodo said in Firewall has rebooted without any strange log entry: Try to raise in the Advanced Configuration Options the Firewall Maximum Table Entries! I can not found such a tunable configuration. Could you please tell me where i can find this option? At the bottom of the attached picture: [image: 1568808113779-firewall-table.png] Regards, fireodo

@Solway said in Android saying "Connected, no Internet": i understand the stateful firewall thing... was hoping to allow known ports and not random stuff. No problem :) Point is, you were reading your capture "wrong" or better "not completely". As you perhaps know, stateful filters filter the traffic by matching the first packet (a SYN packet) against your filter table and allow or block it, then create a state and match traffic to that state so it doesn't have to repeat the lookup process for every single packet of e.g. a download but the first. So you had this part in your capture: 15:57:40.216322 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 0 15:57:40.229403 IP 216.58.206.100.443 > 10.1.1.20.53298: tcp 0 15:57:40.379510 IP 10.1.1.20.53298 > 216.58.206.100.443: tcp 0 and read it like "I must open port 53298". But look what has happened: your client (IP .20) requested a HTTPS connection (port 443 on the remote IP xyz.100) and got an answer from it (2nd line) and afterwards sent data to it (3rd line). So your port 53298 is just that: a random high port a client has to use as per protocol when connecting to a remote server speaking HTTPS. That is specified as "client with random high port >1023 [source] to server port 443 [destination]". All other traffic belonging to this connection is passed through the stateful filter. So no need for opening random ports as it isn't the problem you are looking for. That's why I was telling you, you should instead have a look in "System Logs / Firewall" as there passes or blocks are only listed when matching the filter so no unnecessary packets (like in a tcpdump) are on display. So I'd enable logging on all block/pass rules on your interface the smartphone is connected, disable its WiFi, re-enable it and then check and filter the logs for your android's IP so you only get it to display packets coming from your smartphone and them being passed or blocked. If you see blocked entries, check where they are going and on what port. I assume there are some checking IPs to see if the device has internet connectivity similar to those IPs/Domains/URLs they check to discover if you are behind a portal so they can display their notification that you need to do some portal login.

Logging matching traffic would only ever log the first packet which created the state. Subsequent packets would not be logged. Additionally, since it's ESP, it's possible that the traffic is being passed by an automatic IPsec-related rule and not hitting your logging rule. If there is an existing state for ESP from the source to the destination, then ESP traffic in either direction will be allowed, since it matches the state. Doesn't matter what the rules say unless the states expire or are killed after changing the rules.

@JeGr said in Guest network. Internet access only.: but to widen and increase usage of "TLS"-type protocols instead of unencrypted ones Yeah ok - for where it makes sense sure... But something that is suppose to take ms to perform like a simple dns query has no business having to use tcp and then the even more overhead of tls on top of that.. Web gui interfaces are one thing.. But tcp and tls do nothing but add overhead and complexity to something as simple as dns.. And zero point to adding that on a secure network..

Yeah just use pfsense, with multiple lans is the way to go.. Get rid of whatever shit router that can not do vlans You can do it the way your doing it, but you have to route on each host in the transit network (home lan) in your setup. Telling them to get to 10.1.1. go to 192.168.1.2 vs bouncing it off their default gateway. Other option is to nat at pfsense, and to get to stuff on 10.1.1 just hit pfsense wan IP 192.168.1.2... You have to do port forwards on pfsense for anything you want to able to get to on the network behind it.

@chpalmer Yeah, thats what SPI Firewalls do, they check if incoming connections on WAN where initiated from the lan Interface first, and if so they will pass them through. On a Side to End IPsec VPN my Client initiates the connection, so i didnt understand why the incoming packets from the remote network got blocked. For the Side to Side VPN i did set Ipsec Firewall rules for incoming traffic of the remote network, but i still didnt get it working with the fritzbox on the other side. But thats an other thing i will try again later, first i would really like to understand why the side to End VPN (With VPN Client on the PC) didnt work until i did set the incoming firewall rule (And why its now still working, after the rule got deleted) .

There could be many reason for such blocks.. Anything that could cause no state would block anything other than Syn.. Asymmetrical is quite often an issue if stuff is not working and all you see is those. But those quite often would be lots of SA (syn,ack). Could be a loss of state do to some sort of rest in the firewall, change of IP on the wan, change of wan from primary to a backup. Loss of wan, when reset states are set to do that, etc. If you are seeing a lot of it, then you might want to look deeper.. If you get floods of it now and everything is working as you want, then you could ignore it, not log if it bothers you.. Or look deeper.. Could be bad code on the devices where say if they loose their connection, they are not smart enough to create a new session, and try and use older ones that might have timed out, etc. Those RA's are prob the device not being able to use the session anymore send a RESET.. Trying to tell the other side - hey I'm freaking done with this.. Hope you get this and close it as well.

Out of the box pfsense resolves, and yes clients can ask it for dns on its IP.. And it will then resolve what they ask.. it will walk down from roots to find the authoritative nameserver in question, and then ask that ns for whatever.domain.tld your looking for.. it does not forward anywhere.. No matter what you put in the dns servers under general. The only time those would/could be used is if pfsense itself is looking for something. If you want unbound to forward to 1.1.1.1 then you have to tell unound to forward. [image: 1568475079499-forwardmode.png]

That FIN_WAIT_2:ESTABLISHED is still strange. Maybe something to do with the app itself though. Glad it's working.

you only need to make rules that open the port for smb/cifs between the 2 group

Yes, if you would have mentioned that the NIC was USB we would have zeroed in on it immediately. I just assumed you were using the NIC on your Pi.

@johnpoz no 127.0.0.1 is correct its for openvpn. wan1 has nat to 127.0.0.1:1200 wan2 has nat to 127.0.0.1:1200 openvpn is bound to localhost. now the gateway is important to be set on failover - why? well i have a lot of routers incomming that are not pfsense, they run openvpn 2.4 but in a very minimalistic way. so the best failoverconfiguration so far is Clientside: has 2 remote entrys and short reconnect timeouts. remote 1 goes to wan1 on the pfsense, remote 2 to wan2 Now the trick here is that if wan1 goes down, firewallrule with set to gateway will deny any access to openvpn via wan1 same time cut of any leftovers - thats important in cases where the failover is triggered for like packetloss. in that case clients often stay connected, on a not really useable line. this way they are forced to reconnect. now since the firewall now blocks wan1, they will retry to wan2. wan2 is now active and let them in. however theres no way to bring openvpn back to wan1 once its ok again. not even an eeasy way to determine which client is connect to which wan. This is because i need to iroute my clients subnets into my own. because of this i cannot use a second instance of openvpn (cannot route back without ospf, clients dont support ospf). so i need to use once instance. to solve this i have the gateway directive also on wan2. once failover falls back to wan1, connections will be cut off imidiatly and access to wan2 is blocked. clients now reconnect in their server list and will land eventually back on wan1 and reconnect this works 100% and is so far the best failover for external clients with irouting. Now back to topic, ahh i missunderstodd the gateway option, well need sleep. well for my use case it doenst matter as it works as described, i was just curious why my test rule doenst apply, i wont need that one anyway. i assumed he wont match the packet if gateway does not match. well looks like it does match, but my desired outcome is the same, by intentionally misconfigure the gateway :) well... if it works...it aint stupid :)

thanks for that detailed response. Really helps me get my head around this!!

ok