2

I currently have 2 servers:

Server A: 2.2.2.2

Server B: 3.3.3.3

I want to create a GRE tunnel from server A to server B.

I have ipforwarding enabled on server A:

cat /proc/sys/net/ipv4/ip_forward
1

On server A I setup the tunnel using:

sudo iptunnel add gre2 mode gre local 2.2.2.2 remote 3.3.3.3 ttl 255
sudo ip addr add 192.168.168.1/30 dev gre2
sudo ip link set gre2 up

On server B I used the following commands:

sudo iptunnel add gre2 mode gre local 3.3.3.3 remote 2.2.2.2 ttl 255
sudo ip addr add 192.168.168.2/30 dev gre2
sudo ip link set gre2 up
sudo echo '200 GRE2' >> /etc/iproute2/rt_tables
sudo ip rule add from 192.168.168.0/30 table GRE2
sudo ip route add default via 192.168.168.1 table GRE2

I am able to ping using the GRE tunnel from both servers using

ping 192.168.168.2 (on server A)
ping 192.168.168.1 (on server B)

On Server A I add the following ip-table rules

sudo iptables -t nat -A POSTROUTING -s 192.168.168.0/30 ! -o gre+ -j SNAT --to-source 2.2.2.2
sudo iptables -t nat -A PREROUTING -d 2.2.2.2 -j DNAT --to-destination 192.168.168.2
sudo iptables -A FORWARD -d 192.168.168.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

At this point I cannot ping server A (2.2.2.2) from my local machine, if I remove the following 3 iptable rules I am able to ping server A again. Although if I'm connected to Server A I can still ping 192.168.168.2.

I have tried to use ipip instead of gre, which effectively was replacing mode gre with ipip but I came across the same problem with the iptable rules.

I also already have a GRE tunnel with server B with another server C (3.3.3.3) using the subnet 10.0.0.0, and rt table value of 100 instead of 200. I don't believe this is causing the problem, as I'm using a different subnet and gre name.

Reverse path filtering is also disabled for both tunnels on server B

cat /proc/sys/net/ipv4/conf/gre2/rp_filter
0
cat /proc/sys/net/ipv4/conf/gre1/rp_filter
0

Is there a configuration step that I'm missing here? I'm unsure why these iptable rules are causing external packets to be lost as I already used these in the previous tunnel setup.

user612795
  • 21
  • 2
  • In these cases you always should use `ip route get ...` + multiple simultaneous `tcpdump` commands to get what's going on. You have to know if it goes through the tunnel or not even this. What are *all* of the rp_filter values on server A and B? try this `sysctl -ar '\.rp_filter'`. Then you should edit your nat rules to only let icmp through the tunnel, so you don't lose much network access to debug (there would still be PMTUD issues meanwhile). – A.B Jul 03 '21 at 19:40

0 Answers0