Unable to get HTTP response once tunnel is established.
I am using kubernetes setup. I have setup the IPsec tunnel between pods. I have used service IP to reach the PODB. PODB Service has endpoint as PODBIP to forward the request to POD.
My tunnel is established. But when I am sending the request to HTTP from PODA using Service IP, not getting response from PODB.
If I have shutdown the tunnel , I am able to get the response from PODB using service IP.
I have attached one dig to present my setup.
I have taken the tcpdump from PODA and PODB as well but can't set any HTTP request.
Is there any way where I can see the logs in IPsec. There is no such error in charon.log.
#1 Updated by Tobias Brunner 9 months ago
- Category changed from libstrongswan to configuration
- Status changed from New to Feedback
- Priority changed from High to Normal
You have an IPsec policy that protects traffic between 192.168.48.27/32 and 192.168.129.180/32. So connecting to 10.108.84.12 will not go via IPsec because the policy doesn't match that traffic.
#4 Updated by Akash Mishra 9 months ago
In case 1 - If I used a different IP address for the connection i.e. PODB IP instead of it's service , I am able to connect. But I need to use the service IP as a forwarder to reach to PODB.
In case 2 - , I have updated the rightsubnet on PODB as Service IP i.e. rightsubnet=10.108.84.14/32 and on PODA it's same as previous i.e. 0.0.0.0/0. After that I have tried to initiate the tunnel but getting received TS_UNACCEPTABLE notify, no CHILD_SA built. Logs attached.
Do you suggest that using service IP as per case 2 ,to establish a tunnel is valid scenario to use strongSwan. I am working from last 2-3 weeks and unable to fix this.
This will be a great help.
#5 Updated by Tobias Brunner 8 months ago
After that I have tried to initiate the tunnel but getting received TS_UNACCEPTABLE notify, no CHILD_SA built. Logs attached.
You need to read the log of the responder (the one returning the TS_UNACCEPTABLE notify) to see why that happens. But configuring rightsubnet on PODB to its service address doesn't really make sense (leftsubnet would be more appropriate). However, you would then have the problem that traffic from 192.168.129.180 (the IP PODB presumably uses as source) wouldn't get tunneled, so you'd have to include that too in the traffic selector. The latter will then cause problems because PODA will send traffic to PODB addressed to an IP address that it doesn't know (the service address), likewise the response would come from an IP address PODA doesn't know/expect (the internal IP, not the service IP). So it seems that this setup won't work unless PODA uses PODB's internal address to access it instead of the service address (which would only be used to set up the IKE/IPsec connection). Otherwise, you'd have to terminate the IPsec connection not on PODB but on the host on which PODB runs so you can setup a tunnel between PODA and the service IP.
Alternatively, you might be able to use transport mode (mode=transport) if you only need to secure direct host-to-host connections between the pods. Then the traffic selectors should automatically be modified to match the public/private IP addresses.