R: Re: mtu issue with ipsec tunnel and netfilter snat
Subsystems (2)
Quoted 8 lines · [email protected] wrote:
Quoted 6 lines · On Wednesday 2013-01-09 10:01, [email protected] wrote:
As you can see there are incoming 1500 bytes packets (these are the decrypted ipsec packets) with DF bit set. These packets are never delivered to the final client 10.81.128.176 (the destination address is 172.16.128.1 which is the ip used for SNATing the original ip 10.81.128.176).
Quoted 7 lines
Quoted 5 lines
IMHO this is a mtu issue: 1500 bytes packets cannot be routed inside the ipsec tunnel.
But why
linux_gw_snatis not sending icmp need to frag packets to 10.148.12.23?Perhaps because ICMP was blocked erroneously?
well, I don't see the icmp packets because tcpdump 'see' only the incoming ipsec clear packets. Is there a way to see the outgoing clear ipsec packets with tcpdump?
Quoted 10 lines · On Thursday 2013-01-10 17:46, [email protected] wrote:
Quoted 5 lines · [email protected] wrote:
Quoted 3 lines
But why
linux_gw_snatis not sending icmp need to frag packets to 10.148.12.23?Perhaps because ICMP was blocked erroneously?
well, I don't see the icmp packets because tcpdump 'see' only the incoming ipsec clear packets. Is there a way to see the outgoing clear ipsec packets with tcpdump?
Not with AF_PACKET sockets (tcpdump uses such), but you could with iptables -j LOG, NFLOG and TRACE they can be made visible. If you need the full packet, you can either patch up LOG to call the kernel hexdump functions, or use NFLOG - I think - to deliver it to any userspace program to do further processing. If all else fails, there is also NFQUEUE with which the packet can also be copied to userspace.