Georgi Alexandrov <tehlists@xxxxxxxxxx> writes:Ola,
rowdy wrote:..snipI added rules like the following (but to user chains that I then
added to the input, output and forward chains) to solve my hassles
(clipped from the freeswan link above):
# allow IPsec
#
# IKE negotiations
iptables -I INPUT -p udp --sport 500 --dport 500 -j ACCEPT
iptables -I OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
# ESP encryption and authentication
iptables -I INPUT -p 50 -j ACCEPT
iptables -I OUTPUT -p 50 -j ACCEPT
that's more than pointless as he has INPUT, OUTPUT and FORWARD policies set to ACCEPT and no other rules.
Even so, I'm thankfull for any suggestions.
So, going back to my initial question; How can I go about finding out
where my packets are droped? Since it's most likelly not because of
any netfilter rule entry, who else can decide that a packet can not be
NATed?
--
/Ola Nilsson
Your problem is directly related to NAT. You can not use NAT. ESP will not establish any security association if the source or destination address have been modified, which is exactly what NAT does to your packets. In order for this to work, you need to encapsulate your ESP (IPsec) traffic within either UDP or TCP. NAT-Traversal does this. Different vendors implement this using different ports.protocol, but essentially they are encapsulating the orignal packets, hiding the info from NAT.
The iptable rules above are exactly what you'd need if the tunnel was terminating ON the firewall. But to terminate it PAST the firewall, unless you use public addresses everywhere (no NAT), you will need to encapsulate, and define approriate (additional) rules on your firewall fot the NAT-T port used.
Hope this helps,
Jean
