See https://forum.vyos.io/t/dmvpn-gre-routed-clear-text-when-ipsec-down/9190/24
Specifically, from here down
I would like to be able to block outbound unencrypted GRE and allow it through IPSec as shown in the linked comment.
See https://forum.vyos.io/t/dmvpn-gre-routed-clear-text-when-ipsec-down/9190/24
Specifically, from here down
I would like to be able to block outbound unencrypted GRE and allow it through IPSec as shown in the linked comment.
There is PR https://github.com/vyos/vyos-1x/pull/1516 for T4667 but it brakes all GRE traffic
Interesting article on how and when to match ipsec options: https://thermalcircle.de/doku.php?id=blog:linux:nftables_demystifying_ipsec_expressions
@n.fort Maybe set firewall name <name> rule <rule> ipsec match-gre? This feels a bit hacky though... Almost like match should be its own block and contain ipsec, none, or gre
It looks like outbound encap can be matched via routing expressions:
$ sudo nft list table ip vyos_filter table ip vyos_filter { [...] chain VYOS_OUTPUT_filter { type filter hook output priority filter; policy accept; meta l4proto gre ip daddr 100.123.124.124 log prefix "[ipv4-OUT-filter-100-A]" counter packets 242 bytes 27374 accept comment "ipv4-OUT-filter-100" counter packets 705 bytes 187256 accept comment "OUT-filter default-action accept" } } $ sudo nft insert rule ip vyos_filter VYOS_OUTPUT_filter meta l4proto gre ip daddr 100.123.124.124 rt ipsec exists log prefix '"[ENCRYPTED]"' accept
Then we break the SA so traffic escapes IPsec and travels in the clear:
[ 315.819291] [ENCRYPTED]IN= OUT=eth0.900 SRC=100.123.123.123 DST=100.123.124.124 LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=13495 DF PROTO=47 [ 316.505888] [ENCRYPTED]IN= OUT=eth0.900 SRC=100.123.123.123 DST=100.123.124.124 LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=13773 DF PROTO=47 [ 316.820681] [ENCRYPTED]IN= OUT=eth0.900 SRC=100.123.123.123 DST=100.123.124.124 LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=14079 DF PROTO=47 [ 317.821953] [ipv4-OUT-filter-100-A]IN= OUT=eth0.900 SRC=100.123.123.123 DST=100.123.124.124 LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=14916 DF PROTO=47 [ 318.841505] [ipv4-OUT-filter-100-A]IN= OUT=eth0.900 SRC=100.123.123.123 DST=100.123.124.124 LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=15064 DF PROTO=47 [...] [ 363.897509] [ipv4-OUT-filter-100-A]IN= OUT=eth0.900 SRC=100.123.123.123 DST=100.123.124.124 LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=35778 DF PROTO=47 [ 364.921551] [ipv4-OUT-filter-100-A]IN= OUT=eth0.900 SRC=100.123.123.123 DST=100.123.124.124 LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=36305 DF PROTO=47 [ 365.172589] [ENCRYPTED]IN= OUT=eth0.900 SRC=100.123.123.123 DST=100.123.124.124 LEN=154 TOS=0x00 PREC=0x00 TTL=64 ID=36537 DF PROTO=47 [ 365.173506] [ENCRYPTED]IN= OUT=eth0.900 SRC=100.123.123.123 DST=100.123.124.124 LEN=114 TOS=0x00 PREC=0x00 TTL=64 ID=36538 DF PROTO=47 [ 365.479231] [ENCRYPTED]IN= OUT=eth0.900 SRC=100.123.123.123 DST=100.123.124.124 LEN=112 TOS=0x00 PREC=0x00 TTL=64 ID=36548 DF PROTO=47
Timings match up with tcpdump output.
I'll see if I can whip up a couple of things off this:
For DMVPN, being able to configure the firewall to match specific GRE tunnels and pick out whether they're headed into the maw of IPsec gives us enough functionality to fix this, manually.
It should be possible to do this automatically, maybe with an extra trap-unencrypted option attached to the profile->tunnel binding that will *only* block that specific tunnel def from exchanging unencrypted packets.
I have https://github.com/vyos/vyos-1x/pull/3616 and https://github.com/vyos/vyos-1x/pull/3637 as works in progress.