Then those GRE packets get IPsec encrypted, and I am trying to match the packets in the filter output table where
they are matched as “protocol 50” (ipsec-esp). However, it appears that the packet mark “gre” is no longer there.
Another packet mark that is added to the esp packet in postrouting (for priority) is still there.
And when IPsec is not used, i.e. the GRE packet is sent unencrypted, both these marks are on the packet.
Aren’t packet marks supposed to stay with the packet even when it passes through IPsec?
Yes that is probably what is happening: a new packet is created in the IPsec layer.
However, it would have been nice when the packet marks would be copied over because such packet marks are commonly used to modify the
handling of the packet later in the routing.
I know about the ipsec-policy=out,ipsec matching but it applies only to the original packet, not to the newly created ESP packet.
The IPsec packets pass through the firewall twice: first their original content with the ipsec-policy that will apply to them later, then
the resulting IPsec packet. (on input the order is reverse, of course)
I would like to make sure that only IPsec (ESP) packets containing the desired GRE or L2TP payload get sent by the router, and that any other
packets will be dropped. Thus the idea of marking the packets and selecting on the packet mark for ESP packets. It could also be useful
when prioritizing certain traffic over other at the output queue.
You should still be able to firewall outbound packets, but before their encrypted. Packets destined to the remote network that don’t have the packet mark and going out the wan interface could be dropped. As for prioritizing, I don’t see how it would work. You could prioritize within the IPSec tunnel but not certain IPSec traffic in the overall wan connection.
It would surely be useful when the packet marks stay on. I can work around it or omit certain checks, but it would be better when it was possible to mark IPsec packets.