Project

General

Profile

Issue #3682

Is there a way to mark special case traffic bypass the traffic selectors?

Added by Maha Vasu 8 months ago. Updated 8 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.8.0
Resolution:

Description

Hello,

This is more of a question than issue - is there any way to bypass the traffic selectors for special case traffic either in application or via configuration? If yes, would this translate to bypassing the security policy? Thanks

History

#1 Updated by Tobias Brunner 8 months ago

  • Category set to configuration
  • Status changed from New to Feedback

Have a look at passthrough policies.

#2 Updated by Maha Vasu 8 months ago

Thanks. Instead of the endpoints, can we, for example, exclude UDP packets from encryption for the same IP/endpoints?

#3 Updated by Tobias Brunner 8 months ago

Instead of the endpoints, can we, for example, exclude UDP packets from encryption for the same IP/endpoints?

There is an example right there.

#4 Updated by Maha Vasu 8 months ago

Thanks. Maybe I wasn't clear earlier, but restating with an example:
The goal here is the following:

Client : 10.1.1.1
Server: 10.1.1.2

Client sends traffic over UDP port 5000 to Server

For the most part, we want the traffic bypassed, however, and without provisioning another UDP port, there is a small subset of the packets that we want encrypted.

#5 Updated by Tobias Brunner 8 months ago

For the most part, we want the traffic bypassed, however, and without provisioning another UDP port, there is a small subset of the packets that we want encrypted.

Then use marks on the IPsec policies/SAs and apply this mark via iptables to the packets you want encrypted.

#6 Updated by Maha Vasu 8 months ago

Thanks. This is what I tried,
I'm running a very simple test with IPSEC, where, for a particular UDP port pair, I'm encrypting... The issue I'm running into is that, when the initial udp packet is sent (very small packet, hello world), if the tunnel isn't established and is done on demand, it never makes it on the network. The tunnel (transport mode) is established however, and all subsequent attempts to send this packet work perfectly. This is reproducible on every attempt. There's no trace of the data packets (ESP) on the initiator side using tcpdump, just the IKE negotiation.

Do UDP packets get treated differently and/or are there different considerations when sending UDP payloads over IPSEC, especially if the tunnel is established on demand?

Here is the config (swanctl.conf):

Initiator:

host-host {
local_addrs= %any4
remote_addrs = %any4
local {
auth = pubkey
certs = cert.pem
id = "Omitted"
}
remote {
auth = pubkey
}
children {
local-test {
local_ts = 10.1.1.4/32[udp/8080]
remote_ts = 10.1.1.5/32[udp/5000]
start_action = start
#updown = /usr/local/libexec/ipsec/_updown iptables
esp_proposals = <omitted>
mode = transport
}
}
version = 2
mobike = no
proposals = <omitted>
}

Remote:

host-host {
local_addrs= %any4
remote_addrs = %any4
local {
auth = pubkey
certs = cert.pem
id = "Omitted"
}
remote {
auth = pubkey
}
children {
local-test {
local_ts = 10.1.1.5/32[udp/8080]
remote_ts = 10.1.1.4/32[udp/5000]
start_action = start
#updown = /usr/local/libexec/ipsec/_updown iptables
esp_proposals = <omitted>
mode = transport
}
}
version = 2
mobike = no
proposals = <omitted>
}

Just to clarify this is not using the "marks" approach you had suggested but using source port to differentiate at the moment

#7 Updated by Tobias Brunner 8 months ago

The issue I'm running into is that, when the initial udp packet is sent (very small packet, hello world), if the tunnel isn't established and is done on demand, it never makes it on the network.

Yep, that's always the case on Linux (and on other platforms too actually), the triggering packet is lost. So you have to use a transport or application protocol that is resilient to packet drops (which you must anyway because neither UDP nor IP are reliable protocols, IPsec doesn't change that).

Also available in: Atom PDF