Servers in the Green network unable to access by public IP locally

[Guest]

[smyunus]

Hi,

I am using EFW2.4, I have opened port for some of my local servers (where web services are running), which is accessible from outside my network. But I am unable to access those servers locally by using the public IP and the required ports are allowed in outgoing traffic.

Kindly advise on this issue.

Thanks in advance.

Regards
Yunus

[alokratha]

Hi

I am also facing same kind of issue please advice.

[StephanSch]

This doesn't work. You have to use the local ip. I think it is because your switches are to smart and want to deliver the packets local and not with outgoing traffic. The only way is to put them into blue ore orange.

[mrkroket]

Did you try adding your server names on Network->Edit Hosts?
I think that by flushing DNS cache and manually adding there it could work.

[alokratha]

Hi,

Thanks for the replay. But sometimes i want to point a public ip to a users machine for external access than how to achieve this? Please suggest.

Thank

[rwebb616]

I have the same issue.  This used to work in 2.1.2 (which I'm on currently) but does not work in 2.2 or later  There must be a work-around.

BTW this type of thing is commonly referred to as NAT Reflection

Anyone? 

-Rich

[xsidx]

Hi,

I am using EFW2.4, I have opened port for some of my local servers (where web services are running), which is accessible from outside my network. But I am unable to access those servers locally by using the public IP and the required ports are allowed in outgoing traffic.

Kindly advise on this issue.

Thanks in advance.

Regards
Yunus

The only way I know this will actually work is if you use a DNS server outside your network to reroute your request towards your public ip, this will require something like no-ip.com or a registered dns site. Other then that an internal address should not be requested to regular ip in means of exiting and reentering your network from a public ip when not using NAT.

[rwebb616]

The only way I know this will actually work is if you use a DNS server outside your network to reroute your request towards your public ip, this will require something like no-ip.com or a registered dns site. Other then that an internal address should not be requested to regular ip in means of exiting and reentering your network from a public ip when not using NAT.

DNS doesn't route anything.  All DNS does is changes names to numbers and vice-versa.  Not to say that DNS doesn't play a role, because it does.  The request starts out with a DNS lookup for a name which gets changed to a public IP.  After that, a connection attempt is made to that IP address which happens to be an IP on the Red interface of the firewall for which there is a port forward rule to a device either in the DMZ or in the Green network.  After that, the firewall is not knowing how to deal with the request.  Actually come to think of it, for those of you with a single static IP, to the firewall it would look like the source address and the destination address are the same because NAT would have changed the outbound IP address from a Green IP to the RED IP.  That might be part of the problem.  I'm going to test using SNAT to change the outbound IP to something different from the inbound request and see if that works. 

This is most definitely a firewall rule thing because as I said it is currently working on version 2.1.2 of EFW Community. 

-Rich

[xsidx]

The only way I know this will actually work is if you use a DNS server outside your network to reroute your request towards your public ip, this will require something like no-ip.com or a registered dns site. Other then that an internal address should not be requested to regular ip in means of exiting and reentering your network from a public ip when not using NAT.

DNS doesn't route anything.  All DNS does is changes names to numbers and vice-versa.  Not to say that DNS doesn't play a role, because it does.  The request starts out with a DNS lookup for a name which gets changed to a public IP.  After that, a connection attempt is made to that IP address which happens to be an IP on the Red interface of the firewall for which there is a port forward rule to a device either in the DMZ or in the Green network.  After that, the firewall is not knowing how to deal with the request.  Actually come to think of it, for those of you with a single static IP, to the firewall it would look like the source address and the destination address are the same because NAT would have changed the outbound IP address from a Green IP to the RED IP.  That might be part of the problem.  I'm going to test using SNAT to change the outbound IP to something different from the inbound request and see if that works. 

This is most definitely a firewall rule thing because as I said it is currently working on version 2.1.2 of EFW Community. 

-Rich

^^Agree... I was sorta on this point earlier, except I was hammered, so excuse my drinking for the dns response I put..lol

[jonmccurry]

The only way I know this will actually work is if you use a DNS server outside your network to reroute your request towards your public ip, this will require something like no-ip.com or a registered dns site. Other then that an internal address should not be requested to regular ip in means of exiting and reentering your network from a public ip when not using NAT.

DNS doesn't route anything.  All DNS does is changes names to numbers and vice-versa.  Not to say that DNS doesn't play a role, because it does.  The request starts out with a DNS lookup for a name which gets changed to a public IP.  After that, a connection attempt is made to that IP address which happens to be an IP on the Red interface of the firewall for which there is a port forward rule to a device either in the DMZ or in the Green network.  After that, the firewall is not knowing how to deal with the request.  Actually come to think of it, for those of you with a single static IP, to the firewall it would look like the source address and the destination address are the same because NAT would have changed the outbound IP address from a Green IP to the RED IP.  That might be part of the problem.  I'm going to test using SNAT to change the outbound IP to something different from the inbound request and see if that works. 

This is most definitely a firewall rule thing because as I said it is currently working on version 2.1.2 of EFW Community. 

-Rich

I am having a similar issue - except that it works for a web server running on port 80 (the usual) without doing anything special besides setting up the port forward, yet doing the exact same thing for another web server that is running on port 81 does not work.  I have added outgoing firewall rules to allow 81 - didn't have to add outgoing fw rules for 80 since they were there by default.  For the webserver that runs on port 81 I have tried running it on 80 and changing 81 on the outside to 80 on the inside in the port forwarding setup and have also tried keeping 81 on the outside to 81 in the inside in the port forward setup with, of course, changing the webserver's port and verifying it actually changed by hitting it with its internal address.

So why would this work with one tcp port but not another?  I have tried with proxy completely off and on (only in transparent mode), IDS off and on, content filter is not being used but only because it does not seem to be able to do anything while proxy is in transparent mode.

Very strange.

[xsidx]

This doesn't work. You have to use the local ip. I think it is because your switches are to smart and want to deliver the packets local and not with outgoing traffic. The only way is to put them into blue ore orange.

^^ here is your answer!! for Internal access use your local IP.

You can also go to Proxy>DNS>DNS routing> and add a dns route to your website internally to your local server IP, so you can use a name instead of your local ip. If you are also accessing your server from outside, I would suggest to  the domain and pay the DNS fee, and just set your servers Public IP and make sure that your port forwarding is pointing correctly to it.

I remember trying to the same thing even with out endian in the way, and when I try to reach my server from via public ip on browser it would not load up, at that time I was only running a test on IIS on my pc and wanted to see if it was accessible from outside, all I had was a linksys router as firewall with port forwarding on it. So I ended up connecting to a proxy site and then looking up my public ip in order to access it from outside, and that did work. so this is a way for you to test your site.

[rwebb616]

^^ here is your answer!! for Internal access use your local IP.

xsidx,  if that is the case, then can you tell me why it works in version 2.1.2? 

Is there any Endian project people watching that can chime in here?  Who better than the developers to answer the question?

-Rich

[xsidx]

^^ here is your answer!! for Internal access use your local IP.

xsidx,  if that is the case, then can you tell me why it works in version 2.1.2? 

Is there any Endian project people watching that can chime in here?  Who better than the developers to answer the question?

-Rich

No clue why it works in 2.1.2, but why would you want to access a server on your local network using a public IP?

you did mentioned you where going to run a test using SNAT... how did that go?

[rwebb616]

but why would you want to access a server on your local network using a public IP?

It is easiest to explain this using an example.  I have for example a domain .. call it contoso.com

I have a mail server that is internet accessible for web based email access at mail.contoso.com.  This is a port forward to an internal server on the green network.

My internal dns domain is contoso.local

On a laptop I would like to be able to access web based email using mail.contoso.com from both inside the network and outside the network, however mail.contoso.com resolves to the public IP on the outside of the firewall.  This works fine if I'm outside the network, but while inside the network it doesn't forward. 

I could set my internal dns domain to contoso.com and just set the a record for mail.contoso.com to point to the internal IP instead of the public, but then that also means that I have to manipulate other records say for example the web site. www.contoso.com and point it to the public IP so it will continue to work on the inside of the network.

Does that make sense?

I have not had the time to set the 2.4 firewall back up to do the SNAT test yet.  I will report back when I get that done.

-Rich

[jonmccurry]

^^ here is your answer!! for Internal access use your local IP.

xsidx,  if that is the case, then can you tell me why it works in version 2.1.2? 

Is there any Endian project people watching that can chime in here?  Who better than the developers to answer the question?

-Rich

No clue why it works in 2.1.2, but why would you want to access a server on your local network using a public IP?

you did mentioned you where going to run a test using SNAT... how did that go?

Email is the best example, and even setting internal DNS servers to point to the local (LAN) IP won't always work 100% of the time, in the case that someone has a laptop was last used at home, or internet cafe at lunch, that has cached the DNS entry being your public IP, and worked while at home/internet-cafe but now they're back in the office and now can't connect because the Endian firewall is not doing NAT-reflection or NAT-redirection or whatever other term there is for it.

This could also be an issue with ANY type of server you have on your LAN that is publicly accessible, and would mostly be an issue for yourself and employees.

Being able to access via the public IP means there is zero extra configuration necessary - no special entries for internal DNS servers, no hosts file entries, simple is always better.

What is strangest to me is that it seems to somehow be doing this fine for an internal webserver running on the standard port 80 without doing anything special besides setting up port forwarding, but not for an internal webserver running on non-standard port of 81 (in my case).

Anyone actually have success with this - possibly when running on standard/default ports for the service in question?  I have been tempted to try other services currently not working and temporarily set the port forwards to be on standard ports, but if only we all had more time...