I have some VPN Servr on my lan, and if I enable "“Drop invalid packets” on the router, the router does not send anymore ICMP-redirects.
Is this expected? Are ICMP-redirects "invalid packets"?
Where can i see what the “Drop invalid packets” options does?
- Why does your network experience ICMP Redirecting?
- Does LAN traffic egress thru your LAN VPN instead of via the router?
- Have you created a route that points to the VPN?
(This information can be found on a lot of Linux websites. The same information applies for both netfilter software.)
I think this can be the result of asymmetric routing in which case you have to SNAT the traffic coming out of the VPN server.
1 Like
Yes, that works. But i like it more to be able to connect to VPN clients too (even from one to another), so I disabled the invalid-packets option and hope no realy invalid cause problems 
Maybe it is better if the invalid-packets are filtered only on external, internet interface, eg configure it for each zone
Set proper routes and you will not need icmp redirects.
Thx, but adding additional routes on ALL network clients for ALL vpn subnets is useless work
Routes are usually added to routers - not "all network clients". So it's still unclear why you have this issue.
Well, as absurd as you say it you are doing exactly that - altering route on every machine.
Lets see what is classified invalid.
sysctl net.netfilter.nf_conntrack_log_invalid=255
dmesg | tail -22
it is classified ewhether dropped or no
Have you ensured the client accept the redirect?
Most OS have this disabled.
1 Like
Additionally neither of 2 routers has complete tcp to do firewalling.
Sorry I don't get it what TCP have to do with it?
On a LAN with 192.0.2.0/24, a client wants to connect to 203.0.113.0/24.
But the router -- lets say 192.0.2.1 -- has a route for 203.0.113.0/24 via 192.0.2.23 and sends the icmp redirect to the client.
The client then uses 192.0.2.23 as a gateway, and this gateway is then doing firewalling if configured to do so.
I don't see redirects as an issue. I have used it a few years ago to have -- because of reason -- separated VPN routers in a single LAN segment.
You only have to ensure these days that redirects are sent by the routers, and that these redirect are accepted by clients. But actually this old concept in IPv4 is not that bad. At least it is simpler then running OSPF on all clients 
(With IPv6 each router can just send RA for these remote networks without announcing a prefix to choose addresses from.)
Part of connection receiving redirect will land on other router.
Please try to write complete sentences....
No. Not half the connection. Client to router; router sends redirect; client uses address of other router as nexthop. That's it. Return traffic goes back via the vpn router to the client.
And even if you have to use async routing which is not generally bad, then your router is just a router and should not do any statefull firewalling.
1 Like
To see the log of invalid packets.
Archetypal router does not track connections, but title says firewall is there...
I think the problem is this:
VPN server on LAN
Traffic from a a VPN client to a local LAN client goes directly from VPN server to local LAN client.
The local LAN client does not have a route to the VPN clients so sends traffic to the router, the router has a static route set to the VPN server and will route to the VPN server.
This is asymmetric routing, the router can classify this kind of traffic as invalid and will stop sending it if the INVALID drop rule is active.
I am with @Brada this is not necessarily bad
Not sure if this is only TCP traffic, I vaguely remember that if the router does not see an ACK coming back it will classify as INVALID
For the OP there is a general rule to Drop invalid packets but also on each firewall zone under conntrack settings a rule to explicitly allow invalid traffic for that specific zone
Please show me why the primary router is involved with firewall when a icmp redirect is send.
This also not async routing. IF the return traffic comes through the primary router back, then that would be async routing.
But with RP filter 2 this is no problem.
Also, with conntrackd the connection table could be sync between the two firewall router thingies.
If ICMP redirect would work you would not have asymmetric routing but apparently it does not
Not even sure if the router will send an ICPMP redirect if the traffic is already classified as INVALID?
1 Like
I have no time to build a test net right now... but...
Client ...
- does a route lookup
- chooses the default route
- resolves the gateway IP
- uses the gateway IP as nexthop
- next hop sees an other nexthop, ands sends a redirect back to the client
- client again: resolves other next hop IP
- sends traffic the the other next hop
The main router/firewall should not have any connection entry afterwards, but yes, it should not have any reject/drop rule for that traffic. (I'm not 100% sure if the forward chain is checked or not... But my gut says the forward chain is checked because of the routing decision.)
The main gateway still needs to decide how to process the traffic. But it will not do the forwarding by itself, but rather send the redirect, therefor the traffic never goes through that gateway. There is no async routing involved.
Async routing is if you send traffic through one router (and path) and get the return traffic from another router. And async routing is not bad at all. It is also no sign of a bad design.
And the same for the response. The traffic never hits the main gateway/firewall.
And the other gateway/router/firewall should see that traffic as a new connection; allows it; and the return traffic hits established/related...
(Just to be clear. I don't want to start a fight. And I think it is a good question...)
@fda could you show us your ruleset?
Try
sysctl net.ipv4.icmp_errors_use_inbound_ifaddr=1
by default you can spillerror icmp to different kinda isolated interface.
In practice, I use that setting on an IPENCAP tunnel. Without the setting, errors such as unreachable messages would egress my WAN instead of the tunnel (i.e., where the traffic ingresed).
1 Like