| View previous topic :: View next topic |
| Author |
Message |
murmel Active Member

Joined: 21 Jan 2009 Posts: 24
|
Posted: Thu Jan 22, 2009 11:51 pm Post subject: [SOLVED] Forwarding HTTP/HTTPS to webserver |
|
|
Good morning to everybody! I got a little problem with my Vyatta-configuration and I have no idea what it can be.
I've forwarded http/https/ssh to my webserver with vyatta. Works great for people outside my network. From the outside I can use ssh, http and https to contact it with the external IP and domain name but when on the inside of the network I can only ssh. Http and https doesn't work and everybody on my lan is used to use the external domain name to contact the webserver.
I don't know how much information you need to help me, but just tell me and I'll try to answer it as good as I can.
I hope someone have a solution to this, thanks!
- Simon
Last edited by murmel on Fri Jan 23, 2009 9:44 am; edited 1 time in total |
|
| Back to top |
|
 |
murmel Active Member

Joined: 21 Jan 2009 Posts: 24
|
Posted: Fri Jan 23, 2009 3:07 am Post subject: |
|
|
I've been troubleshooting some more and found out that I in fact can't connect to the ssh-server either. I've found out what the problem is:
If someone from the outside connects to my internet-ip they'll be forwarded as I've configured my nat rules. But if someone from the inside does the same, the nat rules does not apply and all traffic goes to the vyatta server.
| Code: | root@gw# show service nat rule 2
destination {
port 22
}
inbound-interface eth0
inside-address {
address 192.168.0.42
}
protocol tcp
type destination
[edit]
root@gw#
|
|
|
| Back to top |
|
 |
adabbas Super User

Joined: 23 Aug 2008 Posts: 259
|
Posted: Fri Jan 23, 2009 6:21 am Post subject: Re: Forwarding HTTP/HTTPS to webserver - External IP problem |
|
|
| murmel wrote: |
I've forwarded http/https/ssh to my webserver with vyatta. Works great for people outside my network. From the outside I can use ssh, http and https to contact it with the external IP and domain name but when on the inside of the network .... Http and https doesn't work and everybody on my lan is used to use the external domain name to contact the webserver. |
This is usually the result of DNS configuration and not Vyatta related configuration. This question was posted and solved few times in the forums in the past few months alone. So you may want to search for it for more details, but let me try to explain it to you.
When a workstation tries to contact your web server using its external DNS name, this name must be resolved into an IP address. If that query goes to an external DNS then it will give back the external IP address of your network.
This can be solved by a number of ways, the ideal one would be to install an Internal DNS server for your network (wither on Vyatta or on a separate machine) and configure it to responded with the internal IP address when asked for your internal servers by their external names. Or since you have only few workstations, then it would be much easier in your case to edit the hosts files on the workstation and put an entry that points to the internal servers by their internal IP address.
To make sure that what I am talking about is enough to solve your problem without changing your NAT configuration: try to connect to the internal servers by their internal IP address instead of their external name, if all works out then you know for sure that this is what is happening, other than that you should post your configuration for us to see. |
|
| Back to top |
|
 |
murmel Active Member

Joined: 21 Jan 2009 Posts: 24
|
Posted: Fri Jan 23, 2009 8:28 am Post subject: Re: Forwarding HTTP/HTTPS to webserver - External IP problem |
|
|
| adabbas wrote: | | murmel wrote: |
I've forwarded http/https/ssh to my webserver with vyatta. Works great for people outside my network. From the outside I can use ssh, http and https to contact it with the external IP and domain name but when on the inside of the network .... Http and https doesn't work and everybody on my lan is used to use the external domain name to contact the webserver. |
This is usually the result of DNS configuration and not Vyatta related configuration. This question was posted and solved few times in the forums in the past few months alone. So you may want to search for it for more details, but let me try to explain it to you.
When a workstation tries to contact your web server using its external DNS name, this name must be resolved into an IP address. If that query goes to an external DNS then it will give back the external IP address of your network.
This can be solved by a number of ways, the ideal one would be to install an Internal DNS server for your network (wither on Vyatta or on a separate machine) and configure it to responded with the internal IP address when asked for your internal servers by their external names. Or since you have only few workstations, then it would be much easier in your case to edit the hosts files on the workstation and put an entry that points to the internal servers by their internal IP address.
To make sure that what I am talking about is enough to solve your problem without changing your NAT configuration: try to connect to the internal servers by their internal IP address instead of their external name, if all works out then you know for sure that this is what is happening, other than that you should post your configuration for us to see. |
Hello adabbas! Thanks for your reply.
I've been able to connect to the webserver with it's internal IP. But that wasn't my problem. I've always been able to connect to the server with my domain name, and I can when using untangle wich is the gateway I've been using for about a year now. But when I found out about vyatta I felt like merging but there are some stuff that doesn't work..
I think that it's the nat that doesn't accept traffic from the internal network going out and then in again or what ever it does. I just have no clue what the problem really is...
The only thing I know is that:
If someone from the outside uses my domain name to access my webserver or ssh-server, they will go to my web/ssh-server.
If someone from the inside uses my domain name to acces my webserver or ssh-server, they will go to vyatta. |
|
| Back to top |
|
 |
murmel Active Member

Joined: 21 Jan 2009 Posts: 24
|
|
| Back to top |
|
 |
murmel Active Member

Joined: 21 Jan 2009 Posts: 24
|
Posted: Fri Jan 23, 2009 9:38 am Post subject: |
|
|
Yeah, it's done. =)
| Code: |
rule 2 {
destination {
port 443
}
inbound-interface eth0
inside-address {
address 192.168.0.42
}
protocol tcp
type destination
}
rule 3 {
destination {
address 84.xxx.xxx.123
port 443
}
inbound-interface eth1
inside-address {
address 192.168.0.42
port 443
}
protocol tcp
source {
address 192.168.0.0/24
}
type destination
}
|
| Code: | set service nat rule 2
set service nat rule 2 destination port 443
set service nat rule 2 inbound-interface eth0
set service nat rule 2 inside-address address 192.168.0.42
set service nat rule 2 protocol tcp
set service nat rule 2 type destination
set service nat rule 3
set service nat rule 3 destination address 84.xxx.xxx.123
set service nat rule 3 destination port 443
set service nat rule 3 inbound-interface eth1
set service nat rule 3 inside-address address 192.168.0.42
set service nat rule 3 inside-address port 443
set service nat rule 3 protocol tcp
set service nat rule 3 source address 192.168.0.0/24
set service nat rule 3 type destination
set service nat rule 4
set service nat rule 4 destination address 192.168.0.42
set service nat rule 4 destination port 443
set service nat rule 4 outbound-interface eth1
set service nat rule 4 protocol tcp
set service nat rule 4 source address 192.168.0.0/24
set service nat rule 4 type masquerade |
Where 84.xxx.xxx.123 is my external ip. Man, now I'll stop using Untangle when I've made a dns working as I want. |
|
| Back to top |
|
 |
DaveRoberts Vyatta Employee

Joined: 12 Feb 2008 Posts: 518
|
Posted: Fri Jan 23, 2009 1:11 pm Post subject: |
|
|
| You're looking for "hairpin NAT," which we currently don't support (though the workaround you found will help). It's being worked on for the Jenner release. |
|
| Back to top |
|
 |
murmel Active Member

Joined: 21 Jan 2009 Posts: 24
|
Posted: Fri Jan 23, 2009 1:47 pm Post subject: |
|
|
| DaveRoberts wrote: | | You're looking for "hairpin NAT," which we currently don't support (though the workaround you found will help). It's being worked on for the Jenner release. |
Thanks! The work around works great. Don't know if it's really needed, but would make the job much simpler when forwarding ports. Will the Jenner release have a port forward function that makes it easier to forward ports and include "hairpin nat"?
I feel that this is something that I use all the time and I don't know that much about NAT and I would had a much easier time if there was a wiki och sticky with links to threads that explains how to do stuff like this in a easy-for-newbies way.
Just an idea.
Thanks for all your hard work, Vyatta have totally blown me away! Your CLI totally rule all other CLI/GUI-based open source routers!
- Simon
Btw, take a look at the post I made here. Maybe you know what I'm looking for: http://www.vyatta.org/forum/viewtopic.php?t=1391 |
|
| Back to top |
|
 |
tshire2 Forum Newbie

Joined: 18 Jan 2009 Posts: 1
|
Posted: Fri Jan 23, 2009 9:49 pm Post subject: The this the answer to the problem :) |
|
|
I have tested this config with a router with 2, 3, and 4 interfaces and it works well in all different configs
see the this doc:
http://www2.vyatta.com/s.nl/ctype.KB/it.I/id.6859/KB.424/.f
| Quote: |
The Vyatta router has an external public IP 172.16.0.2 and an internal private IP 192.168.0.1. In this setup, the administrator has three requirements to resolve five issues.
1. The administrator has a number of public addresses ( 172.16.0.0/28 ) that they would like to map to several servers on the internal private network. For example, the administrator wants to map the public IP 172.16.0.5 to the server with private IP 192.168.0.5. Furthermore, they would like these servers to be accessible from the Internet using the corresponding domain names, for example, "www.your-domain.com" should point to the public IP 172.16.0.5 (which is in turn mapped to 192.168.0.5). The name "your-domain" in "www.your-domain.com" represents your domain and must be modified accordingly.
2. A client machine on the internal private network should also be able to access the servers using the domain name. Note, however, that the administrator does not have an internal DNS server, so when an internal client accesses "www.your-domain.com", for example, it will actually get the public IP 172.16.0.5 from the external DNS server.
3. All machines on the internal private network should be able to access the "www.your-domain.com" Server using the external IP Address that is mapped to the internal private network. Note: This simulates an external users connection.
4. All machines on the "external network"/internet should be able to access the "www.your-domain.com" Server using the external IP Address that is mapped to the internal private network.
5. All machines on the internal private network should be able to access the Internet, i.e., "masquerade" is required.
Please view the network diagrams below to better understand how the translations are made.
The diagram below represents the internal private network user browsing to the following url "http://www.your-domain.com" and illustrates an external DNS resolution only. Note: internal DNS is not present.
|
Check it out. |
|
| Back to top |
|
 |
|