I want to create a gre tunnel using my wireless router's wan interface to a laptop(gre-server) connected to its wan interface directly via an ethernet cable.
My aim is to create a GRE tunnel in my router and i want to route all my client's packets connected to my router's wireless interface through that GRE tunnel.
Commands used in my router
ip link add gretunnel link <wan_interface> type gretap remote <gre_server_ip>
ip link set gretunnel up
brctl addbr gre-br
brctl addif gre-br gretunnel #Here i am adding my gretunnel to the created bridge.
brctl addif gre-br ra0 #Where ra0 is my wireless interface through which my wireless
#clients's packets will be received & transmitted.
ifconfig gre-br up
Commands used in my gre-server laptop.
ip link add greserver link <interface_connected_to_router> type gretap remote <router's_wan_ip>
ip link set greserver up
ifconfig greserver 10.170.20.1 netmask 255.255.255.0 up
ifconfig greserver up
Note:
Icmp traffic from the client is successfully being sent to greserver, from gre-server it successfully reaches internet, but when i try to create or start any tcp or http communication from the client, the tunnel gets teared down, or some change occurs so that after that even my icmp requests are not being answered.
It is observed that the icmp request is forwarded to gre-server for which even gre-server responds, but the reply of gre-server is not being received in my router's wan interface, given the fact that the greserver and router is connected back to back without any other device sitting in between.
I have added the following rule in my router's firewall
config rule
option name Allow-GRE
option src wan
option proto gre
option target ACCEPT
I have the following packages installed in my router
gre - 1-3
kmod-gre - 3.18.21-1
kmod-gre6 - 3.18.21-1
kmod-ipt-nat - 3.18.21-1
kmod-nf-nat - 3.18.21-1
kmod-nf-nathelper - 3.18.21-1
kmod-nf-nathelper-extra - 3.18.21-1
kmod-lib-textsearch - 3.18.21-1
It is a very simple topology, router & my gre-server is connected back to back. with no other specific configs or devices.
Seeing "product" suggests to me that this is going into deployment on the public Internet. Chaos Calmer, due to its age does not include security patches for kernel, application software, or wireless vulnerabilities. If you are a commercial enterprise, you could potentially be help responsible for either damage to your direct customers, or if your product becomes compromised and is used as a jump point in an attack on another target.
Unless you're running on some very custom hardware, it surprises me that "upgrading it to latest will be a huge effort activity"
In current releases of OpenWrt, GRE is typically configured and handled through netifd with UCI configuration.
Your problem is likely related to not handling fragmentation properly. GRE adds an encapsulation header, which takes the 1500-byte "full" packets on your Ethernet-like links to 1524 bytes. Fragmentation then occurs within the tunnel itself. PMTU fails because the true source of the packet is inside the encapsulation, so there is no way for the tunnel to determine the host to which to send the ICMP message. This is a protocol / Linux limitation, not specific to OpenWrt.
Thank you Jeff and tmomas for you replies, even if the link MTUs are adjusted, the issue seems to occur, but i observe that the packets are not being dropped but they are being not decapsulated by my router, due to that my clients receive packets with GRE headers so they end up dropping all the packets.
But the same scenario resumes after sometime, the same router without any change in setup, resumes to properly decapsulate the packets and send it to client.
This looks to be a wierd issue, i am using openwrt 15.05 with kernel version 3.18, my gre version is 1.3.
Any insights in this regard will be highly helpful
GRE tunneling works quote well with OpenWrt 18.06 and UCI configuration.
OpenWrt 15.05 is, as previously described, known insecure and unpatched for several years. It is not supported and not supportable. Kernel 3.18 was EOLed nearly two years ago, at the beginning of 2017.