# Inbound packet loss on GRE tunnel

## fincoop

Hello all,

This is a new configuration of a GRE tunnel, and I have extensive networking background. I have never tried to make a GRE tunnel work on Linux. The trouble is, packets are policy-based routed out to the GRE tunnel, but any packets that return are dropped and I cannot explain why.

I used iptables with TRACE and here is what I see. Outbound:

```
May  3 19:43:20 firewall kernel: TRACE: raw:PREROUTING:policy:3 IN=eth0 OUT= MAC=00:26:b9:bc:7e:22:38:c9:86:55:98:03:08:00 SRC=192.168.11.123 DST=153.104.63.227 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=13595 DF PROTO=TCP SPT=57735 DPT=80 SEQ=2889648645 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303050101080A1063D1660000000004020000) 

May  3 19:43:20 firewall kernel: TRACE: mangle:PREROUTING:rule:1 IN=eth0 OUT= MAC=00:26:b9:bc:7e:22:38:c9:86:55:98:03:08:00 SRC=192.168.11.123 DST=153.104.63.227 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=13595 DF PROTO=TCP SPT=57735 DPT=80 SEQ=2889648645 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303050101080A1063D1660000000004020000) 

May  3 19:43:20 firewall kernel: TRACE: mangle:PREROUTING:policy:5 IN=eth0 OUT= MAC=00:26:b9:bc:7e:22:38:c9:86:55:98:03:08:00 SRC=192.168.11.123 DST=153.104.63.227 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=13595 DF PROTO=TCP SPT=57735 DPT=80 SEQ=2889648645 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303050101080A1063D1660000000004020000) MARK=0xc8 

May  3 19:43:20 firewall kernel: TRACE: nat:PREROUTING:policy:5 IN=eth0 OUT= MAC=00:26:b9:bc:7e:22:38:c9:86:55:98:03:08:00 SRC=192.168.11.123 DST=153.104.63.227 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=13595 DF PROTO=TCP SPT=57735 DPT=80 SEQ=2889648645 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303050101080A1063D1660000000004020000) MARK=0xc8 

May  3 19:43:20 firewall kernel: TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=vpn0 MAC=00:26:b9:bc:7e:22:38:c9:86:55:98:03:08:00 SRC=192.168.11.123 DST=153.104.63.227 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=13595 DF PROTO=TCP SPT=57735 DPT=80 SEQ=2889648645 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303050101080A1063D1660000000004020000) MARK=0xc8 

May  3 19:43:20 firewall kernel: TRACE: filter:FORWARD:rule:1 IN=eth0 OUT=vpn0 MAC=00:26:b9:bc:7e:22:38:c9:86:55:98:03:08:00 SRC=192.168.11.123 DST=153.104.63.227 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=13595 DF PROTO=TCP SPT=57735 DPT=80 SEQ=2889648645 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303050101080A1063D1660000000004020000) MARK=0xc8 

May  3 19:43:20 firewall kernel: TRACE: filter:FORWARD:rule:2 IN=eth0 OUT=vpn0 MAC=00:26:b9:bc:7e:22:38:c9:86:55:98:03:08:00 SRC=192.168.11.123 DST=153.104.63.227 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=13595 DF PROTO=TCP SPT=57735 DPT=80 SEQ=2889648645 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040568010303050101080A1063D1660000000004020000) MARK=0xc8 

May  3 19:43:20 firewall kernel: TRACE: mangle:POSTROUTING:rule:9 IN= OUT=vpn0 SRC=192.168.11.123 DST=153.104.63.227 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=13595 DF PROTO=TCP SPT=57735 DPT=80 SEQ=2889648645 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040568010303050101080A1063D1660000000004020000) MARK=0xc8 

May  3 19:43:20 firewall kernel: TRACE: mangle:POSTROUTING:policy:10 IN= OUT=vpn0 SRC=192.168.11.123 DST=153.104.63.227 LEN=64 TOS=0x08 PREC=0x00 TTL=63 ID=13595 DF PROTO=TCP SPT=57735 DPT=80 SEQ=2889648645 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040568010303050101080A1063D1660000000004020000) MARK=0xc8 

May  3 19:43:20 firewall kernel: TRACE: nat:POSTROUTING:policy:5 IN= OUT=vpn0 SRC=192.168.11.123 DST=153.104.63.227 LEN=64 TOS=0x08 PREC=0x00 TTL=63 ID=13595 DF PROTO=TCP SPT=57735 DPT=80 SEQ=2889648645 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040568010303050101080A1063D1660000000004020000) MARK=0xc8
```

That looks like a complete traversal of iptables on the way out, and inbound...

```
May  3 19:43:20 firewall kernel: TRACE: raw:PREROUTING:policy:3 IN=vpn0 OUT= MAC= SRC=153.104.63.227 DST=192.168.11.123 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=21587 DF PROTO=TCP SPT=80 DPT=57735 SEQ=3084792399 ACK=2889648646 WINDOW=65535 RES=0x00 ACK SYN URGP=0 OPT (02040568010303050402080A8EF4E08F1063D166) 

May  3 19:43:20 firewall kernel: TRACE: mangle:PREROUTING:policy:5 IN=vpn0 OUT= MAC= SRC=153.104.63.227 DST=192.168.11.123 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=21587 DF PROTO=TCP SPT=80 DPT=57735 SEQ=3084792399 ACK=2889648646 WINDOW=65535 RES=0x00 ACK SYN URGP=0 OPT (02040568010303050402080A8EF4E08F1063D166) 
```

Well, there is no raw:PREROUTING policy 3, nor is there a mangle:PREROUTING policy 5. I suppose that means there was no match in those tables, and that's all there is, no more output from TRACE. I guess the next step would have read nat:PREROUTING:policy:5. There is nothing in my nat:PREROUTING table that could explain this. I imagine there is a lot of information missing, but I would appreciate your thoughts on things that I could try to fix this.

/etc/conf.d/net

```
iptunnel_vpn0="mode gre local <my-ip> remote <remote-ip> ttl 255"

mtu_vpn0="1424"

config_vpn0="172.18.56.97/30 peer 172.18.56.98"

routes_vpn0="default via 172.18.56.98 dev vpn0 metric 10 table <custom>"

rules_vpn0="fwmark 200 priority 5300 table <custom>"

```

I have several other interfaces and routing or masquerading is working fine there.

iptables raw table:

```
>>> iptables -t raw -L -n

Chain PREROUTING (policy ACCEPT)

target     prot opt source               destination         

TRACE      all  --  153.104.63.227       0.0.0.0/0           

TRACE      all  --  0.0.0.0/0            153.104.63.227      

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination         

TRACE      all  --  153.104.63.227       0.0.0.0/0           

TRACE      all  --  0.0.0.0/0            153.104.63.227      

```

----------

## manaka

Hi!!

When setting a GRE tunnel, you need iptables rules for both the original (non-tunneled) packets and the tunneled ones. I.e, you need to allow the packets to go through the GRE interface and also to allow the GRE packets to go through your normal interface (eth0 or whatever). This is one of the tricky things when setting an scenario like yours. Double check you have rules for both things.

You could also try debugging your issue with tcpdump. It's easier than with Netfilter TRACE and may also hint you in the right direction.

Hope this helps a bit!!

----------

