Score:1

IP Binding Issue in using GRE Tunnel

co flag

I have a issue with tunneling and am having a hard time finding a solution. I have two servers, A: Host-Server being a sever with a single IP, and B: Main-Server being the server handling all our applications.

I set up the GRE tunnel fine, but for the application need the (A) server IP ( 192.168.0.1 ) to be on (B) servers Eth0 so the application can use the IP as its own (this is a must). However when I attempt to add the (A) IP to (B) i believe a routing loop is happening, and I cannot figure out how to get traffic to flow correctly. I have tried some PREROUTE and POSTROUTE on iptabels with little success. Below is the setup I get to where everything stops working.

Any help in this would be greatly appreciated!

Details:

Server A: Host:

Public IP: 192.168.0.1
Tunnel IP: 10.0.2.1

Server B: Main:

Public IP: 192.168.1.2
Tunnel IP: 10.0.2.2

Server A:

Add the Tunnel

sudo ip tunnel add test_tunnel mode gre local 192.168.0.1 remote 192.168.1.2 ttl 255
sudo ip addr add 10.0.2.1/30 dev test_tunnel
sudo ip link set test_tunnel up
sudo echo '101 test_tunnel_GRE' >> /etc/iproute2/rt_tables
/sbin/ip route add default via 10.0.2.2 dev test_tunnel table test_tunnel_GRE
/sbin/iptables -t nat -A POSTROUTING -s 10.0.2.0/30 ! -o gre+ -j SNAT --to-source 192.168.0.1
/sbin/iptables -A FORWARD -d 10.0.2.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -s 10.0.2.2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Test the Tunnel IPs to ping and see if response is given (Works).

root@A:~# ping -c4 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=50.6 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=64 time=49.6 ms
64 bytes from 10.0.2.2: icmp_seq=3 ttl=64 time=49.7 ms
64 bytes from 10.0.2.2: icmp_seq=4 ttl=64 time=49.7 ms

--- 10.0.2.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 49.636/49.945/50.651/0.439 ms

Test on Server should see Tunnel Server IP: (Works)

root@A:~# curl http://www.cpanel.net/showip.cgi --interface 10.0.2.1
192.168.0.1

Server B:

Add the Tunnel

sudo ip tunnel add test_tunnel mode gre local 192.168.1.2 remote 192.168.0.1 ttl 255
sudo ip addr add 10.0.2.2/30 dev test_tunnel
sudo ip link set test_tunnel up
sudo echo '101 test_tunnel_GRE' >> /etc/iproute2/rt_tables
/sbin/ip rule add from 10.0.2.0/30 table test_tunnel_GRE
/sbin/ip route add default via 10.0.2.1 dev test_tunnel table test_tunnel_GRE

Test the Tunnel IPs to ping and see if response is given (Works).

[root@B~]# ping -c4 10.0.2.1
PING 10.0.2.1 (10.0.2.1) 56(84) bytes of data.
64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=51.7 ms
64 bytes from 10.0.2.1: icmp_seq=2 ttl=64 time=50.0 ms
64 bytes from 10.0.2.1: icmp_seq=3 ttl=64 time=50.0 ms
64 bytes from 10.0.2.1: icmp_seq=4 ttl=64 time=50.0 ms

--- 10.0.2.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3054ms
rtt min/avg/max/mdev = 50.023/50.458/51.721/0.746 ms

Test on Server should see Tunnel Server IP: (Works)

[root@B~]# curl http://www.cpanel.net/showip.cgi --interface 10.0.2.2
192.168.0.1

Here is where it breaks:

Add IP to eth0:

ip a a 192.168.0.1/32 dev eth0
/sbin/ip rule add from 192.168.0.1 table test_tunnel_GRE

BROKEN

Now everything breaks on both ends, on both servers ping and curl both fail to respond.

I appreciate any info that can help me get this resolved!

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.