What is the proper way of configuring port forwarding through an Openvpn tunnel from one site to another in a site to site configuration?
The usual port forwarding does not work, even the one site sees the other IP and route is set up for the defined remote subnet. The packets are either not transmitted via tunnel or the reply from the subnet node is lost.
Make the forward on the inbound device.
Can you show us this firewall config from the remote inbound device?
You don't need port forwarding at all because there is no need for NAT in such scenario.
Once the routing is set up properly you only need to configure your firewall zone(s) and rule(s).
2 Likes
Then how does OP send packet from VPS to the OpenWrt?
(Which has Private IPs)
The port forwarding is needed for an outside service.
I have taken following tries:
- forward from ovpn server directly to remote node
- forward from ovpn server to the remote router node, from the remote router node to the remote node
- forward from ovpn server to the opvn client, forward from ovpn client to remote node
In all of these scenarios the remote node had no information about the reply path to the source originating the tcp request. The ovpn is a routed tun configuration site to site with a separate outer connection.
The remote node lies on the remote network and port forwarding on the remote network works fine, only via IP tunnel it does not seem to work.
What is the mechanism of port forwarding vs packet encapsulation? Is it possible that we either reach the packet size limit or similar?
Both sites have its own public ip. These are privately held sites, no VPS
There is no VPS in this setup.
My understanding that we're discussing a basic routing scenario with 3 subnets that looks (on the logical level) like this:
LAN1--R1--(vpn)--R2--LAN2
For this discussion both R1 and R2 have 2 interfaces (in 2 zones) - one for LAN and one for VPN.
The task is to allow incoming traffic on R2 from VPN interface to LAN2 and the same on the other side.
2 Likes
My bad, I've confused 2 different topics on the forum.
2 Likes
Correct. This is the current setup. As said, only port forwarding between sites is not working. Something that we would hit the limit of L3.
Please forget about port forwarding, read my first answer.
2 Likes
I analysed the connection with tcpdump. The packets were forwarded directly to the service server and replied the same path, but the lenght of the packets was truncated to zero bytes. So the connection via firewall seems to be ok, but some network metrics is prohibiting the data transfer.
19:21:22.060804 IP ip-12.34.56.78.inet.com.9587 > homedomain.lan.http: Flags [S], seq 2305033384, win 65535, options [mss 1358,sackOK,TS val 3683761813 ecr 0,nop,wscale 9], length 0
19:21:22.061047 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9587: Flags [S.], seq 1403733398, ack 2305033385, win 28960, options [mss 1460,sackOK,TS val 369014083 ecr 3683761813,nop,wscale 7], length 0
19:21:22.235496 IP ip-12.34.56.78.inet.com.9603 > homedomain.lan.http: Flags [S], seq 1689134469, win 65535, options [mss 1358,sackOK,TS val 3683762064 ecr 0,nop,wscale 9], length 0
19:21:22.235655 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9603: Flags [S.], seq 281743175, ack 1689134470, win 28960, options [mss 1460,sackOK,TS val 369014257 ecr 3683762064,nop,wscale 7], length 0
19:21:23.048754 IP ip-12.34.56.78.inet.com.9587 > homedomain.lan.http: Flags [S], seq 2305033384, win 65535, options [mss 1358,sackOK,TS val 3683762832 ecr 0,nop,wscale 9], length 0
19:21:23.048953 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9587: Flags [S.], seq 1403733398, ack 2305033385, win 28960, options [mss 1460,sackOK,TS val 369015071 ecr 3683761813,nop,wscale 7], length 0
19:21:23.261584 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9603: Flags [S.], seq 281743175, ack 1689134470, win 28960, options [mss 1460,sackOK,TS val 369015283 ecr 3683762064,nop,wscale 7], length 0
19:21:23.326914 IP ip-12.34.56.78.inet.com.9603 > homedomain.lan.http: Flags [S], seq 1689134469, win 65535, options [mss 1358,sackOK,TS val 3683763090 ecr 0,nop,wscale 9], length 0
19:21:23.327039 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9603: Flags [S.], seq 281743175, ack 1689134470, win 28960, options [mss 1460,sackOK,TS val 369015349 ecr 3683762064,nop,wscale 7], length 0
19:21:24.061613 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9587: Flags [S.], seq 1403733398, ack 2305033385, win 28960, options [mss 1460,sackOK,TS val 369016083 ecr 3683761813,nop,wscale 7], length 0
19:21:25.256384 IP ip-12.34.56.78.inet.com.9587 > homedomain.lan.http: Flags [S], seq 2305033384, win 65535, options [mss 1358,sackOK,TS val 3683764848 ecr 0,nop,wscale 9], length 0
19:21:25.256560 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9587: Flags [S.], seq 1403733398, ack 2305033385, win 28960, options [mss 1460,sackOK,TS val 369017278 ecr 3683761813,nop,wscale 7], length 0
19:21:25.307322 IP ip-12.34.56.78.inet.com.9603 > homedomain.lan.http: Flags [S], seq 1689134469, win 65535, options [mss 1358,sackOK,TS val 3683765104 ecr 0,nop,wscale 9], length 0
19:21:25.307447 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9603: Flags [S.], seq 281743175, ack 1689134470, win 28960, options [mss 1460,sackOK,TS val 369017329 ecr 3683762064,nop,wscale 7], length 0
19:21:27.261599 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9587: Flags [S.], seq 1403733398, ack 2305033385, win 28960, options [mss 1460,sackOK,TS val 369019283 ecr 3683761813,nop,wscale 7], length 0
19:21:27.325562 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9603: Flags [S.], seq 281743175, ack 1689134470, win 28960, options [mss 1460,sackOK,TS val 369019347 ecr 3683762064,nop,wscale 7], length 0
19:21:30.225757 IP ip-12.34.56.78.inet.com.9603 > homedomain.lan.http: Flags [R.], seq 1:49, ack 4013224121, win 0, length 48: HTTP
19:21:31.453610 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9603: Flags [S.], seq 281743175, ack 1689134470, win 28960, options [mss 1460,sackOK,TS val 369023475 ecr 3683762064,nop,wscale 7], length 0
19:21:31.453743 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9587: Flags [S.], seq 1403733398, ack 2305033385, win 28960, options [mss 1460,sackOK,TS val 369023475 ecr 3683761813,nop,wscale 7], length 0
19:21:39.645630 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9587: Flags [S.], seq 1403733398, ack 2305033385, win 28960, options [mss 1460,sackOK,TS val 369031667 ecr 3683761813,nop,wscale 7], length 0
19:21:39.645766 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9603: Flags [S.], seq 281743175, ack 1689134470, win 28960, options [mss 1460,sackOK,TS val 369031667 ecr 3683762064,nop,wscale 7], length 0
19:21:55.773620 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9603: Flags [S.], seq 281743175, ack 1689134470, win 28960, options [mss 1460,sackOK,TS val 369047795 ecr 3683762064,nop,wscale 7], length 0
19:21:55.773758 IP homedomain.lan.http > ip-12.34.56.78.inet.com.9587: Flags [S.], seq 1403733398, ack 2305033385, win 28960, options [mss 1460,sackOK,TS val 369047795 ecr 3683761813,nop,wscale 7], length 0
Can you try icmp and/or another server or service?
Is it possible to verify that the reply is going the same path back? To me seems that the http start sequence is never going to finish and the reply is going back from different public ip.
ip route get <DST_IP> from <IP_of_SRC_Interface>
1 Like
Most likely the packets are traveling back the wrong way. When I switch the default gateway on the service server to the gateway on the other end of the tunnel, am I going to solve the reply problem or just introduce network problem?
Don't do that.
I suggest you draw a diagram with all the subnets shown and also show the routing table from the server side gateway.
Also check this: I have a site to site openvpn system - #19 by AndrewZ
The routes on site to site connection is okay. The sites are working as expected, but when forwarding data from GW2 (green path), the reply gets back through GW1 and not the Tunnel. The packets are then dropped by the client.
Show the actual subnets (IP/mask) and the routing table.
1 Like
To get the replies back through GW2, you need to SNAT the requests to the openvpn server's IP address.
Note that in this case you will not be able to see the IP addresses of the initiators in the logs of the remote node (if that's important to you).
Good idea. In fact I can do a SNAT on the operator router before the GW2, but I must admit that I have hard times to do that. The target system is RouterOS and when I inserted a snat rule to overwrite the source IP before the dst-nat forwarding rule, no traffic passed via that rule.
Tcpdump showed no source address was replaced.
Let's say you need redirection GW2:8888=>Service_server:80
# ovpn server
config redirect
option name 'Redirect-1'
option src 'wan'
option dest 'lan'
list proto 'tcp'
option src_dport '8888'
option dest_ip '192.168.8.2'
option target 'DNAT'
config nat
option name 'SNAT-1'
option src 'lan'
list proto 'tcp'
option dest_ip '192.168.8.2'
option dest_port '8888'
option snat_ip '192.168.8.1'
option target 'SNAT'
# ovpn client
config redirect
option name 'Redirect-2'
option src 'wan'
option dest 'lan'
list proto 'tcp'
option src_dport '8888'
option dest_ip '192.168.2.135'
option dest_port '80'
option target 'DNAT'
The request will arrive on behalf of 192.168.8.1 (not some public IP), so the reply will be returned to that address and then back to the initiator via GW2.