elenium3
commented
4 months ago same issue. Previously same config worked fine
Open Crivera2809 opened 4 months ago
elenium3
commented
4 months ago same issue. Previously same config worked fine
mvisser-nhb
commented
2 months ago have you tried adding sourceip?
for example:
ping -n -c 4 -I {current_host_ip} {target}
Crivera2809
commented
2 months ago Thank you very much for your help @mvisser-nhb.
Yes, I did it, but it doesn't work, I've tried some workaround but I've not had success.
ping from E1. `$ ping -n -c 4 -I 10.0.7.252 172.31.84.135 PING 172.31.84.135 (172.31.84.135) from 10.0.7.252 : 56(84) bytes of data.
--- 172.31.84.135 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3078ms`
tcpdump in E2.
$ sudo tcpdump -n -i ip_vti0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ip_vti0, link-type RAW (Raw IP), capture size 262144 bytes 00:56:37.613542 IP 10.0.7.252 > 172.31.84.135: ICMP echo request, id 24, seq 1, length 64 00:56:38.643963 IP 10.0.7.252 > 172.31.84.135: ICMP echo request, id 24, seq 2, length 64 00:56:39.667940 IP 10.0.7.252 > 172.31.84.135: ICMP echo request, id 24, seq 3, length 64 00:56:40.691936 IP 10.0.7.252 > 172.31.84.135: ICMP echo request, id 24, seq 4, length 64
letoams
commented
2 months ago Show the output of “ipsec trafficstatus” and see if the outgoing or incoming counter remains at zero after a few pings.If outgoing remains zero, a NAT rule might change source IP before IPsec subsystem.If incoming counter remains zero, perhaps the other end has a bad NAT rule or firewall rule.Sent using a virtual keyboard on a phoneOn Jun 18, 2024, at 21:07, Crivera2809 @.***> wrote:
Thank you very much for your help @mvisser-nhb.
Yes, I did it, but it doesn't work, I've tried some workaround but I've not had success.
ping from E1.
$ ping -n -c 4 -I 10.0.7.252 172.31.84.135 PING 172.31.84.135 (172.31.84.135) from 10.0.7.252 : 56(84) bytes of data. --- 172.31.84.135 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3078ms
tcpdump in E2.
$ sudo tcpdump -n -i ip_vti0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ip_vti0, link-type RAW (Raw IP), capture size 262144 bytes 00:56:37.613542 IP 10.0.7.252 > 172.31.84.135: ICMP echo request, id 24, seq 1, length 64 00:56:38.643963 IP 10.0.7.252 > 172.31.84.135: ICMP echo request, id 24, seq 2, length 64 00:56:39.667940 IP 10.0.7.252 > 172.31.84.135: ICMP echo request, id 24, seq 3, length 64 00:56:40.691936 IP 10.0.7.252 > 172.31.84.135: ICMP echo request, id 24, seq 4, length 64
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Crivera2809
commented
2 months ago Hello @letoams
Thank you very much for your help,
I've tried ping test from Ip 10.0.7.252 to 172.31.84.135 and I've checked with command “ipsec traffic status" and I see something similar to what you have indicated, I will investigate if the problem is being caused by a NAT rule.
000 Total IPsec connections: loaded 1, active 1 000 000 State Information: DDoS cookies not required, Accepting new IKE connections 000 IKE SAs: total(2), half-open(0), open(0), authenticated(2), anonymous(0) 000 IPsec SAs: total(2), authenticated(2), anonymous(0) 000 000 #4: "western":4500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 84804s; newest ISAKMP; lastdpd=2s(seq in:0 out:0); idle; 000 #5: "western":4500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 85496s; lastdpd=2s(seq in:18908 out:0); idle; 000 #6: "western":4500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 27896s; isakmp#5; idle; 000 #6: "western" esp.308ed5a@54.86.xx.xx esp.1abe74a2@10.0.7.252 tun.0@54.86.xx.xx tun.0@10.0.7.252 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B 000 #7: "western":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27195s; newest IPSEC; eroute owner; isakmp#4; idle; 000 #7: "western" esp.c003f931@54.86.xx.xx esp.a87b4f9@10.0.7.252 tun.0@54.86.xx.xx tun.0@10.0.7.252 ref=0 refhim=0 Traffic: ESPin=43KB ESPout=50KB! ESPmax=4194303B
Thanks a lot!
Best regards
Hello, please I need help, I have set up an IPSEC tunnel between 2 Amazon AWS accounts with Libreswan 4.12. Tunnel is up and running, but network traffic inside the tunnel goes only from one end to the other, but no return traffic is observed when pinging the local private ip of each end.
When I try to ping from the private ip of the EC2 instance in account A, to the private ip of the EC2 instance in account B on AWS, I see ICMP requests coming through to the other end, but I don't see a response.
Tunnel established between AWS accounts.
Instance at End A.
$ ping 10.0.7.252 PING 10.0.7.252 (10.0.7.252) 56(84) bytes of data.
--- 10.0.7.252 ping statistics --- 21 packets transmitted, 0 received, 100% packet loss, time 20460ms
Instance at End B.
As you can see if traffic is sent from one end to the other, but without response. To try to solve this problem I added a return route in the routing table which in theory should route the traffic to the ip_vti0 interface of the VPN, but it had no effect.
Instance at End A.
Instance at End B.
Please does anyone have any suggestions or advice to solve this problem. Why is the traffic going only in one direction? If I ping each end of the EC2 instances the traffic is received at each end, but I don't get any response back.
Thanks in advance!