Project

General

Profile

Issue #3513

Pass through https on overlapping subnets

Added by Rakesh Patil 2 months ago. Updated about 2 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.7.2
Resolution:

Description

I have a requirement, wherein all the traffic to and from the VM should be encrypted. Additionally, https traffic should be excluded from encryption as its already encrypted by SSL/TLS. I have the following config but it doesnt seem to work. Either, I am able make trap-any work or pass-https work but never both.

Following is my config :

On server where https is running -

conn pass-https
authby=never
also=trap-any
left=127.0.0.1
right=127.0.0.1
leftsubnet=10.0.0.0/8[tcp/443]
type=pass
auto=route

conn trap-any
rightsubnet=10.0.0.0/8,192.168.0.0/16
leftsubnet=10.0.0.0/8,192.168.0.0/16
type=pass
authby=psk
auto=route

On initiator -
conn trap-any
rightsubnet=10.0.0.0/8,192.168.0.0/16
leftsubnet=10.0.0.0/8,192.168.0.0/16
type=transport
authby=psk
auto=route

Please suggest modifications.

History

#1 Updated by Rakesh Patil 2 months ago

Update ------
I am able to exclude port for example 80 from ipsec, but all other traffic to the VM drops.

Server -
conn pass-http
leftsubnet=10.0.1.4/32[tcp/80]
rightsubnet=10.0.0.0/8
type=passthrough
auto=route

conn trap-any
left=%any
right=%any
rightsubnet=10.0.0.0/8
type=transport
authby=psk
auto=route

Client -
conn pass-http
left=%any
rightsubnet=10.0.1.4/32
type=passthrough
auto=route

conn trap-any
left=%any
right=%any
rightsubnet=10.0.0.0/8
type=transport
authby=psk
auto=route

#2 Updated by Tobias Brunner 2 months ago

  • Status changed from New to Feedback

Using port/protocol-specific passthrough policies don't work if routes are installed that override them (routes don't care for the ports/protocol). You could use marks to prevent traffic from getting tunneled.

#3 Updated by Rakesh Patil 2 months ago

Tobias Brunner wrote:

Using port/protocol-specific passthrough policies don't work if routes are installed that override them (routes don't care for the ports/protocol). You could use marks to prevent traffic from getting tunneled.

Can you please suggest, how to use marks. Do I also need to create VTI interfaces to be able to use marks? As seen above, I m using transport mode to encrypt all communications within a subnet/VNET.
I need passthrough policy to only bypass a port/protocol from encryption.

On basis of your suggestion, I tried to use mark in following manner but couldnt achieve what I m looking for. Any suggestion would be helpful.
-----------

When I add connmark.conf under /etc/strongswan/strongswan.d/charon/ and apply mark=100 to pass-http, All traffic is dropped.

When I add connmark.conf under /etc/strongswan/strongswan.d/charon/ and apply mark=100 to trap-any, All traffic is passthrough'ed .

When I add connmark.conf under /etc/strongswan/strongswan.d/charon/ and apply mark=%unique to pass-http on client (initiator), All traffic is encrypted

When I add connmark.conf under /etc/strongswan/strongswan.d/charon/ and apply mark=%unique to trap-any on client (initiator), http passthrough works but other traffic is dropped.

When I add connmark.conf under /etc/strongswan/strongswan.d/charon/ and apply mark=%unique to pass-http on server, All traffic is dropped

When I add connmark.conf under /etc/strongswan/strongswan.d/charon/ and apply mark=%unique to trap-any on server, All traffic is passthrough'ed


Thanks

#4 Updated by Tobias Brunner 2 months ago

Can you please suggest, how to use marks.

You'd do so via the mark* config options and iptables rules that set marks on specific traffic. The marks can also be used to override routes etc.

Do I also need to create VTI interfaces to be able to use marks?

No, this has nothing to do with VTI interfaces.

On basis of your suggestion, I tried to use mark in following manner but couldnt achieve what I m looking for.

This has nothing to do with the connmark plugin, which is for very specific use cases.

In your scenario this might not actually be necessary to use marks (no virtual IPs). You might want to debug what's actually going on, perhaps your policies are simply wrong or there is still a problem with the route(s) installed in table 220 (you can disable the latter via charon.install_routes).

#5 Updated by Rakesh Patil 2 months ago

Tobias Brunner wrote:

Can you please suggest, how to use marks.

You'd do so via the mark* config options and iptables rules that set marks on specific traffic. The marks can also be used to override routes etc.

Do I also need to create VTI interfaces to be able to use marks?

No, this has nothing to do with VTI interfaces.

On basis of your suggestion, I tried to use mark in following manner but couldnt achieve what I m looking for.

This has nothing to do with the connmark plugin, which is for very specific use cases.

In your scenario this might not actually be necessary to use marks (no virtual IPs). You might want to debug what's actually going on, perhaps your policies are simply wrong or there is still a problem with the route(s) installed in table 220 (you can disable the latter via charon.install_routes).

If I specify protocol/port value in rightsubnet on client :
Client -
conn pass-http
left=127.0.0.1
rightsubnet=10.0.1.4/32[tcp/http]
type=passthrough
auto=route

Server -
conn pass-http
authby=never
left=127.0.0.1
leftsubnet=10.0.1.4/32[tcp/http]
type=passthrough
auto=route

Client initiates IKE SA --- This shouldnt happen
Server responds. Communication is encrypted :
Client Logs -

Jul 23 00:06:15 client2 charon: 09[KNL] creating acquire job for policy 10.0.2.4/32[tcp/6] === 10.0.1.4/32[tcp] with reqid {1}
Jul 23 00:06:15 client2 charon: 09[IKE] initiating IKE_SA trap-any1 to 10.0.1.4
Jul 23 00:06:15 client2 charon: 09[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jul 23 00:06:15 client2 charon: 09[NET] sending packet: from 10.0.2.4500 to 10.0.1.4500 (1108 bytes)
Jul 23 00:06:15 client2 charon: 11[NET] received packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:06:15 client2 charon: 11[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jul 23 00:06:15 client2 charon: 11[IKE] 10.0.1.4 is initiating an IKE_SA

If I remove protocol/port value in rightsubnet on client :
Client -
conn pass-http
left=127.0.0.1
rightsubnet=10.0.1.4/32
type=passthrough
auto=route

conn trap-any
left=%any
right=%any
rightsubnet=10.0.0.0/8
type=transport
authby=psk
auto=route

Passthrough works fine for port80 with client and server both communicating without initiating SA.

For other port communication, example ICMP, client doesnt initiate SA -- which shouldn't be happening and it should have generated SA.
but server still generates SA ---- Server is working fine by generating SA
and since client doesnt respond with SA, traffic is dropped.

Server Logs -
Jul 23 00:16:01 servervm1 systemd: Started Session 7501 of user root.
Jul 23 00:16:02 servervm1 systemd: Removed slice User Slice of root.
Jul 23 00:16:04 servervm1 charon: 04[KNL] creating acquire job for policy 10.0.1.4/32[udp/47361] === 10.0.2.4/32[udp/blackjack] with reqid {1}
Jul 23 00:16:04 servervm1 charon: 03[IKE] initiating IKE_SA trap-any1 to 10.0.2.4
Jul 23 00:16:04 servervm1 charon: 03[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jul 23 00:16:04 servervm1 charon: 03[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:16:08 servervm1 charon: 06[IKE] retransmit 1 of request with message ID 0
Jul 23 00:16:08 servervm1 charon: 06[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:16:16 servervm1 charon: 05[IKE] retransmit 2 of request with message ID 0
Jul 23 00:16:16 servervm1 charon: 05[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:16:28 servervm1 charon: 08[IKE] retransmit 3 of request with message ID 0
Jul 23 00:16:28 servervm1 charon: 08[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:16:52 servervm1 charon: 07[IKE] retransmit 4 of request with message ID 0
Jul 23 00:16:52 servervm1 charon: 07[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:17:02 servervm1 systemd: Created slice User Slice of root.
Jul 23 00:17:02 servervm1 systemd: Started Session 7502 of user root.
Jul 23 00:17:02 servervm1 systemd: Removed slice User Slice of root.
Jul 23 00:17:34 servervm1 charon: 09[IKE] retransmit 5 of request with message ID 0
Jul 23 00:17:34 servervm1 charon: 09[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:18:01 servervm1 systemd: Created slice User Slice of root.
Jul 23 00:18:01 servervm1 systemd: Started Session 7503 of user root.
Jul 23 00:18:01 servervm1 systemd: Removed slice User Slice of root.
Jul 23 00:18:49 servervm1 charon: 10[KNL] creating delete job for CHILD_SA ESP/0x00000000/10.0.2.4
Jul 23 00:18:49 servervm1 charon: 10[JOB] CHILD_SA ESP/0x00000000/10.0.2.4 not found for delete
Jul 23 00:18:49 servervm1 charon: 12[IKE] giving up after 5 retransmits
Jul 23 00:18:49 servervm1 charon: 12[IKE] establishing IKE_SA failed, peer not responding

So all in all, it seems client is not obeying protocol/port attribute on its rightsubnet.

#6 Updated by Tobias Brunner about 2 months ago

Client initiates IKE SA --- This shouldnt happen
Server responds. Communication is encrypted :
Client Logs -

Jul 23 00:06:15 client2 charon: 09[KNL] creating acquire job for policy 10.0.2.4/32[tcp/6] === 10.0.1.4/32[tcp] with reqid {1}

The packet (or whatever else it was) that triggered the acquire and the SA has no remote port associated. The passthrough policy should still apply to packets with destination port 80 afterwards.

For other port communication, example ICMP, client doesnt initiate SA -- which shouldn't be happening and it should have generated SA.

Not if the passthrough policy is for the IPs and has no protocol/port-specific restrictions. Also note the UDP-based acquire when using ping due to a source address lookup done by the tool (you can avoid that via -I option).

Jul 23 00:16:04 servervm1 charon: 03[IKE] initiating IKE_SA trap-any1 to 10.0.2.4
Jul 23 00:16:04 servervm1 charon: 03[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jul 23 00:16:04 servervm1 charon: 03[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:16:08 servervm1 charon: 06[IKE] retransmit 1 of request with message ID 0
Jul 23 00:16:08 servervm1 charon: 06[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:16:16 servervm1 charon: 05[IKE] retransmit 2 of request with message ID 0
Jul 23 00:16:16 servervm1 charon: 05[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:16:28 servervm1 charon: 08[IKE] retransmit 3 of request with message ID 0
Jul 23 00:16:28 servervm1 charon: 08[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)
Jul 23 00:16:52 servervm1 charon: 07[IKE] retransmit 4 of request with message ID 0
Jul 23 00:16:52 servervm1 charon: 07[NET] sending packet: from 10.0.1.4500 to 10.0.2.4500 (1108 bytes)

Why is that IKE traffic blocked?

#7 Updated by Rakesh Patil about 2 months ago

Sorry for the delayed response. Also for some reasons, I am unable to submit response by quoting your text.

"The packet (or whatever else it was) that triggered the acquire and the SA has no remote port associated. The passthrough policy should still apply to packets with destination port 80 afterwards."

Yes, the communication that client triggered has no remote port associated. I too dont understand why, even when I mention server's remote protocol/port in right subnet on client. Can you please check this config and let me know if its fine based on my requirements ?

"Why is that IKE traffic blocked?

Because the client always initiates communication without IKE SA and behaves all traffic is passthrough when I don't mention remote protocol/port in rightsubnet. The server however responds with an IKE SA and the client drops the packet other than port 80. The problem is with client config and the way it initiates communication. Can you please verify my client configs and suggest modification or do you think its a bug ?

#8 Updated by Tobias Brunner about 2 months ago

Yes, the communication that client triggered has no remote port associated. I too dont understand why, even when I mention server's remote protocol/port in right subnet on client. Can you please check this config and let me know if its fine based on my requirements ?

That has nothing to do with the policies/config, but with what the client application does when opening/connecting the socket and how the kernel handles this.

You could maybe try to initiate the connection manually before connecting to port 80 and then check if that traffic bypasses the established tunnel.

Because the client always initiates communication without IKE SA and behaves all traffic is passthrough when I don't mention remote protocol/port in rightsubnet. The server however responds with an IKE SA and the client drops the packet other than port 80.

IKE traffic should never be affected by configured policies (the daemon installs socket-specific passthrough policies for the IKE sockets, you'll see these with ip xfrm policy).

Also available in: Atom PDF