1

Perhaps somebody can enlighten me... I think I have a problem in IPTables but no idea anymore...

I have an IPSEC site-2-site tunnel between a pfSense server and a virtual machine with strongswan. I'm using iptables to forward traffic from the host the virtual machine is running on to the virtual machine

iptable rules:

iptables -t nat -A POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT<br/>
iptables -t nat -A PREROUTING -i eno1 -p udp -d externalip --dport 500 -j DNAT --to-destination 10.49.10.35<br/>
iptables -t nat -A PREROUTING -i eno1 -p udp -d externalip --dport 4500 -j DNAT --to-destination 10.49.10.35<br/>
iptables -A FORWARD -p udp -d 10.49.10.35 --dport 500 -j ACCEPT<br/>
iptables -A FORWARD -p udp -d 10.49.10.35 --dport 4500 -j ACCEPT<br/>
iptables -t nat -A POSTROUTING -p udp -s 10.49.10.35 --sport 500 -j SNAT --to-source externalip<br/>
iptables -t nat -A POSTROUTING -p udp -s 10.49.10.35 --sport 4500 -j SNAT --to-source <externalip>

The IPSEC tunnel is setup correctly ( I think ) because when it's connected I can ping the pfsense machine and the VM with the IPSec endpoint using there internal ip's back and forth.

From the pfsense machine to VM:

ping -S 10.130.20.1 10.49.30.35
PING 10.49.30.35 (10.49.30.35) from 10.130.20.1: 56 data bytes
64 bytes from 10.49.30.35: icmp_seq=0 ttl=64 time=12.248 ms
64 bytes from 10.49.30.35: icmp_seq=1 ttl=64 time=12.265 ms
64 bytes from 10.49.30.35: icmp_seq=2 ttl=64 time=12.327 ms
64 bytes from 10.49.30.35: icmp_seq=3 ttl=64 time=12.286 ms

From the IPSEC VM to pfSense

PING 10.130.20.1 (10.130.20.1) 56(84) bytes of data.
64 bytes from 10.130.20.1: icmp_seq=1 ttl=64 time=12.2 ms
64 bytes from 10.130.20.1: icmp_seq=2 ttl=64 time=12.2 ms
64 bytes from 10.130.20.1: icmp_seq=3 ttl=64 time=12.1 ms
64 bytes from 10.130.20.1: icmp_seq=4 ttl=64 time=12.1 ms

So that all seems Ok, but when I enter an extra machine in the setup behind the IPSecVM ping etc isn't possible anymore.
I've set net.ipv4.ip_forward = 1 on the IPSecVM.

So now when I do a ping fro pfsense to my new test machine (10.49.10.36)

ping -S 10.130.20.1 10.49.30.36
PING 10.49.30.36 (10.49.30.36) from 10.130.20.1: 56 data bytes
^C
--- 10.49.30.36 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

When I run tcpdump -i ens19 host 10.130.20.1 on my test machine I see the traffic comming in but no replies are being sent back

12:48:03.432489 IP 10.130.20.1 > 10.49.30.36: ICMP echo request, id 2145, seq 0, length 64
12:48:04.434735 IP 10.130.20.1 > 10.49.30.36: ICMP echo request, id 2145, seq 1, length 64
12:48:05.435699 IP 10.130.20.1 > 10.49.30.36: ICMP echo request, id 2145, seq 2, length 64
12:48:06.443736 IP 10.130.20.1 > 10.49.30.36: ICMP echo request, id 2145, seq 3, length 64
12:48:07.454943 IP 10.130.20.1 > 10.49.30.36: ICMP echo request, id 2145, seq 4, length 64

Than thinking it was about routing i've added a route on the testvm:

route add -net 10.130.20.0/24 gw 10.49.10.35

But then still no traffic is being sent back...

The reason I think that it has something to do with the iptables is that i have similar setups where strongswan runs directly on on the host machine instead of a VM and then everything works.

I'm probably just forgetting something stupid, but after a couple of days of thinkering, I just don't see it anymore.

Hopyefully somebody can help me.

5
  • Could you clarify "still no traffic is being sent back" after you added the route (which is required unless the IPsec VM is already the default gateway for the test host). Do you mean the test host doesn't reply at all, or that while the response is sent and arrives at the IPsec VM, no encrypted packets are sent out, or that encrypted packets are returned, but still no response is actually received on 10.130.20.1? – ecdsa Jul 13 '18 at 14:39
  • While I have tcpdump running ( after adding the route ) I see ICMP packages being received on the testmachine, but no replies going out. Also with tcpdump running on the ipsecvm i see packages passing through to the test machine but no replies going back – Rex de Koning Jul 13 '18 at 17:46
  • Sounds like a problem on your test VM. How does the routing table there look like (use ip route list table all)? Any firewall rules (iptables-save)? – ecdsa Jul 16 '18 at 8:30
  • Hi ecdsa.... I feel so stupid... Was able to get it working yesterday evening... I was routing traffic from my testvm, via the wrong interface. :-( Thanks for your replies! – Rex de Koning Jul 17 '18 at 9:49
  • Great. You might want to answer your own question with your solution. – ecdsa Jul 17 '18 at 9:56
0

Turned out that I was routing traffic through the wrong interface. I was trying to get it working for a while and then you overlook the stupistest thing. After stepping back for a while a making a drawing of the situation I found out. Thanks to ecda for the comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.