I’ve configured a site2site tunnel using OpenVPN. This works like a charm. But I noticed I did not have to reconfigure my firewall to make this happen.
name OUTSIDE-LOCAL {
default-action drop
rule 10 {
action accept
state {
established enable
related enable
}
}
rule 11 {
action drop
state {
invalid enable
}
}
rule 12 {
action drop
destination {
port 1195
}
protocol udp
}
}
receive-redirects disable
send-redirects enable
source-validation disable
syn-cookies enable
twa-hazards-protection disable
}
interfaces {
ethernet eth0 {
address x.x.x.x/24
description “WAN”
duplex auto
firewall {
local {
name OUTSIDE-LOCAL
}
}
smp_affinity auto
speed auto
openvpn vtun1 {
local-address 172.16.4.1 {
}
local-host x.x.x.x
local-port 1195
mode site-to-site
protocol udp
remote-address 172.16.4.2
remote-host y.y.y.y
remote-port 1195
shared-secret-key-file /config/auth/mykey.psk
}
}
I’ve tried everything to drop the Vyos-destined OpenVPN traffic on UDP 1195, but bo matter what I try, the tunnel keeps beeing established and functional.
It scares me a bit.
Could someone point out what I might be doing wrong here?
‘firewall local’ applies firewalling for packets ingress on that interface, as per the context sensitive CLI help:
[code]vyos@vygw01# set interfaces ethernet eth0 firewall
Possible completions:
in Ruleset for forwarded packets on inbound interface
local Ruleset for packets destined for this router
out Ruleset for forwarded packets on outbound interface
[/code]
So your rule 12 will only match packets ingress on eth0 that are UDP 1195.
However, I think you have that instance of VyOS acting as a client to the remote server ‘172.16.4.2’. So your router will make an egress connection on UDP 1195 to 172.16.4.2, which will result in a stateful entry installed in conntrack, and thus reply packets will match rule 10 (permit established or related traffic).
Put rule 12 above rule 10 and you should see drops on ingress UDP 1195 to eth0.
Thanks for your quick response. You are right. When I re-number rule 12 to rule 9 the tunnel goes down.
What still puzzles me is how the tunnel ever got established…
The remote site has the same config (IP’s reversed offcourse) so I assume there is no client-server-architecture here.
When both sites have rule 12 to drop all UDP traffic on port 1195, I would assume a tunnel never could have been established in the first place. But it does.
Obviously I’m not looking to actually drop this traffic, because I want to tunnel to establish, but I want to understand why it gets through my firewall. I’m a newbee to Vyos so I’m not really familiar with the troubleshooting of it.
(P.S. you mentioned the router makes an egress connection to 172.16.4.2 but that’s not the case. 172.16.4.0/30 is the subnet on the tunnel. The actual connection is made to the remote-host (not remote-address) y.y.y.y.)
I can’t be certain for your environment, but consider that UDP is connectionless, so what happens for conntrack entries for UDP is a timeout is stored with the entry. If packets are not received within timeout seconds, the entry becomes stale and removed from the ‘established’ set of flows.
It might possible that your nodes generated the stateful triggering first packet prior to your firewall setup, and hence the entry is never expired even after you installed a firewall to prevent it from establishing (as long as frequenty enough packets kept the conntrack entry alive). To test this, reboot both firewalls and I would expect UDP 1195 to match rule 12.
show conntrack table ipv4
Will also help you to identify ‘established’ flows.
Definitely a good thing to understand what’s going on - last thing we need is more network equipment on the Internet configured by people not understanding what is going on & leaving stuff open
Your theory makes sense. So I rebooted both routers (simultaneously). But ‘unfortunatly’ the tunnels came up and on both routers and there is a connection in the conntrack table ipv4 on UDP port 1195.
Maybe the OpenVPN part is started before the firewall engine.
I’m afraid I have to accept not understanding why this happens (a bug maybe?). Or perhaps someone else has an explanation for this.
That is a fine piece of information to understand firewalling on a Vyos/Vyatta router, but only strengthens my concern that the OpenVPN tunnel manages to establish a tunnel whilst UDP traffic for port 1195 is to be dropped on both sides for non-related/non-established connections.
