Welcome, Guest. Please login or register.
Did you miss your activation email?
Wednesday 27 November 2024, 08:22:40 pm

Login with username, password and session length

CLICK HERE for the The official Endian Roadmap and Issue tracker
14261 Posts in 4377 Topics by 6517 Members
Latest Member: Sandro
Search:     Advanced search
+  EFW Support
|-+  Support
| |-+  General Support
| | |-+  EFW Community Routing Issue
0 Members and 0 Guests are viewing this topic. « previous next »
Pages: [1] Go Down Print
Author Topic: EFW Community Routing Issue  (Read 14486 times)
123B3n
Jr. Member
*
Offline Offline

Posts: 1


« on: Saturday 24 June 2017, 11:36:34 am »

Hello,

I'm not really show how to explain what I need, all I'm saying I'm quite new to EFW to begin with and I have no clue how to resolve this. I'm running EFW Community on a dedicated server box where I have several IPs assigned to different VMS.
So far it's all going good, my main issue is for each VM to communicate with their assigned IP not the local IP.

To be specific, lets say VM1 needs to communicate with VM2, VM1 is assigned to IP 5.35.86.145 (Not the real ip) and VM2  is assigned to IP 5.35.86.147 (Not the real ip).
VM1 trys to send a signal over the assigned WAN IP to VM2, it gets denied. Why and how can I resolve this?

Sure I can use the local IP however I don't want to use I'm using them in my DNS records for different things such as game servers etc.
This is all I can see from the firewall log related to the IP:
Code:
INPUT:DROP eth1 (eth1) 92.222.184.1: -> 145.239.54.55:00:50:56:0a:2f:34:00:01:05:17:ff:fd:08:00-
Logged
Dark-Vex
Sr. Member
****
Offline Offline

Posts: 105


« Reply #1 on: Monday 03 July 2017, 05:10:50 pm »

Hello, you need to perform a NAT Loopback rule in order to reach the server with their Public IP Address, below an example of a NAT Loopback with Endian

https://en.wikipedia.org/wiki/Network_address_translation#NAT_loopback

is a feature in many consumer routers which permits the access of a service via the public IP address from inside the local network. This eliminates the need for using separate domain name resolution for hosts inside the network than for the public network for a website, for example.

public ip:1.2.3.4

server private ip:192.168.0.1

server network 192.168.0.0/24

Endian ip:192.168.0.254

GOAL:

you need to access 192.168.0.1 from 192.168.0.100 using the public ip 1.2.3.4 on port 8090

Why it won't work only with DNAT?

when you try to reach the local ip using the public one (DNAT rule matched) the packets that reach the internal server is built in this way

source ip:192.168.0.100

destination ip:1.2.3.4

 then the DNAT rule will change the destination address,and it will be

source ip:192.168.0.100

destination ip:192.168.0.1

 in this way when the packet reach the server 192.168.0.1 has the real ip address,and the server 192.168.0.1 will try to reply directly (since in same subnet of 192.168.0.100) and the source host will drop this reply.

As a workaround,just add a SNAT rule,in order to change also the source ip *AFTER* the DNAT rule will be matched,in this way the reply will be routed back correctly

 Instructions:

from firewall > port forwarding/nat create a rule like this:

[you should already have this one i think if the service is reachable from outside]
incoming ip --> uplink main:IP:1.2.3.4
Incoming Service/Port -->tcp:8090
Translate to ---> 192.168.0.1
Port/Range-->tcp:8090

then go to from firewall > port forwarding/nat > snat and create a rule like this:
Source --> network/ip --> 192.168.0.0/24
Destination -> network/ip --> 192.168.0.1
Service/Port ---> 8090
nat to source address -> 192.168.0.254

In this way you are able to reach the internal server using the public ip address.
In this way the internal server will see always the connection coming from the ip of the endian zone you have chosen and not the real ip of the server that is trying to establish the connection.
Logged
Pages: [1] Go Up Print 
« previous next »
Jump to:  

Page created in 0.078 seconds with 19 queries.
Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Design by 7dana.com