0

This is my setup:

  +--------------------+     +-------------------+  +--------------------+
  | Router B         a +-----+ Router+Firewall C |  | b         Router D |
  |       10.10.10.1 ----------------------------------10.10.10.2        |
  |                    +-----+                   |  |                    +--- more nets
  |       192.168.10.1 |     |192.168.2.11       +--+192.168.2.57        |
  +----|---------------+     +-------------------+  +--------------------+
       |                                                 |                
  +----|---------------+                            +----|---------------+
  |192.168.10.11       |                            |192.168.2.38        |
  |Server A            |                            |Client E            |
  |                    |                            |                    |
  |                    |                            |                    |
  +--------------------+                            +--------------------+
  • Routers B and C have public IPs on the internet and a IpSec tunnel (Racoon) for 192.168.10.1-192.168.2.57.
  • All machines are running Ubuntu Linux.
  • There is an embedded GRE tunnel between 192.168.10.1-192.168.2.57 with the tunnel IPs 10.10.10.1 and 10.10.10.2.
  • The tunnel is required to be able route data from the 192.168.10.0/24 net to other networks behind router D (eg. 192.168.3.0/24).
  • Every IP can ping every other IP.
  • If client E opens a web page on server A, TCP/IP handshake and the "GET /" arrive at server A, but the (large) response of server A does not arrive at client E, but is lost "in" the GRE tunnel.
  • I thought we louse large packets due to fragmentation and reduced the MTU on interfaces a and b, in the end down to 1000 bytes, but this did not help.
  • tcpdump on interface a shows the correct HTTP traffic
  • tcpdump on interface b shows the handshake and HTTP traffic from E->A, but does not show the large response packets from A->E.
  • tcpdump on Router+Firewall C shows the GRE packets dropping out of the IpSec tunnel, no large packets arrive
  • HTTP request from B->E works fine.
  • Large packets between D<->B not via the GRE but directly in the IpSec tunnel (i.e. ssh 192.168.10.1 on the 192.168.2.57 interface) work
  • Large packets between B and "more nets" work (via GRE tunnel!).
  • Swapping the roles of A and E does not help. (E as the server, A as the client or large packets in the other direction don't work.)

Now I am stuck. Any advice what to check? Which config would help to diagnose? Thanks a lot!

Matthias Wuttke
  • 123
  • 1
  • 9
  • The IpSec tunnel is 192.168.10.1/32 <-> 192.168.2.57/32. On the one side (192.168.10.1), it catches packets originating from the gateway. On the other side (on the host 192.168.2.11), it catches packets from 192.168.2.57. Interestingly, after taking the GRE tunnel down, 192.168.2.57 and 192.168.10.1 cannot see each other anymore; but the VPN tunnel is up. 1) Should I have another router on the "10" side as well, or 2) should I make a VPN tunnel that ends on 192.168.2.11/32? But the GRE tunnel should extend to the 192.168.2.57. – Matthias Wuttke Dec 14 '17 at 20:08

2 Answers2

2

The default table is filter, so when you provide a rule like iptables -A FORWARD ... you just put the rule in filter table. There are also several another tables and table mangle is one of them. As of man iptables: "This table is used for specialized packet alteration."

So, for editing a packages (which is done by -j TCPMSS --set-mss) one should use a mangle table, that is why the rule should be like:

iptables -t mangle -A FORWARD -i tun+ -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

Yura Poltoratskiy
  • 21
  • 2
1

You forgot about MSS

1 ) You must set mtu on gre tunnel 1400

2 ) For SYN packets set mss at same size mtu 1400

in linux:

iptables -I FORWARD -i tun+ -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

user3809680
  • 26
  • 2