SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0000453: Can't access server behind vpn from public ip of the vpn gateway after port forward - MantisBT
MantisBT - Endian Firewall
View Issue Details
0000453Endian FirewallNetwork related (VPN, uplinks)public2008-01-12 19:252008-04-23 17:41
Daloia 
peter-endian 
normalmajoralways
closedfixed 
2.2-beta2 
2.2-beta42.2-beta4 
0000453: Can't access server behind vpn from public ip of the vpn gateway after port forward
We have 7 firewall in vpn, the first act as gateway, other 6 like client. On the gateway firewall we have a public ip and we want to use it to make public some servers that are in remote offices. We made the vpn, the gateway can see all the machine behind the vpn, clients can see other client from remote office and the gateway can see the clients in remote office. Some of this clients are webserver and we want to make them public. We configured ports forward on the gateway that has the public ip on the red, but trying to access from internet don't works! We can access the firewall gui of the gateway from the public ip, but no one of the port forward we made works. All the firewall machine are endian firewall in a routed enviroment.
No tags attached.
related to 0000530closed peter-endian portforwarding: make DNAT's optionally automatically also do SNAT rules for the responses 
parent of 0000594closed peter-endian port forwarding should have an option to automatically SNAT 
Issue History
2008-01-12 19:25DaloiaNew Issue
2008-01-12 19:25DaloiaStatusnew => assigned
2008-01-12 19:25DaloiaAssigned To => peter-endian
2008-01-13 15:06mlebelNote Added: 0000804
2008-01-14 11:41peter-endianNote Added: 0000816
2008-01-14 12:24DaloiaNote Added: 0000820
2008-01-29 19:04peter-endianNote Added: 0000865
2008-01-29 19:06peter-endianNote Added: 0000866
2008-01-29 19:10peter-endianRelationship addedrelated to 0000530
2008-01-29 19:11peter-endianStatusassigned => confirmed
2008-01-29 19:11peter-endianRelationship replacedchild of 0000530
2008-01-29 19:11peter-endianRelationship replacedparent of 0000530
2008-01-29 19:11peter-endianRelationship replacedrelated to 0000530
2008-01-30 00:32DaloiaNote Added: 0000868
2008-03-04 15:28peter-endianRelationship addedparent of 0000594
2008-03-04 15:29peter-endianTarget Version => 2.2-beta4
2008-03-06 11:03peter-endianStatusconfirmed => resolved
2008-03-06 11:03peter-endianFixed in Version => 2.2-beta4
2008-03-06 11:03peter-endianResolutionopen => fixed
2008-04-23 17:41peter-endianStatusresolved => closed

Notes
(0000804)
mlebel   
2008-01-13 15:06   
Hi Daloa,

Not an expert here but have you opened up system access for the same ports/protocols that are used in port forward? without these two it's never worked for me.

Hope this helps,
Marc
(0000816)
peter-endian   
2008-01-14 11:41   
is the openvpn client user of the firewall with the target webserver you like to make public set on the openvpn server to "Direct all client traffic through the VPN server"?

If not, the portforward will send packets through the vpn to the target webserver, but the target webserver returns the packets to the endian firewall, which has a default gateway pointing to it's uplink instead of the endian firewall with the openvpn server. So the responses will exit the wrong uplink
(0000820)
Daloia   
2008-01-14 12:24   
our scenario is the second one... so we can't use the vpn as we imagined to do right? we have to direct all the traffic through the vpn server to make it work.. i'm right? no other solutions?
(0000865)
peter-endian   
2008-01-29 19:04   
it's only not implemented currently. However you can insert the necessary iptables rules manually.

We faced the problem a while ago and are aware now of it. So we will implement it, after 2.2 that it works out of the box.

the rule is (on your firewall with the vpn client):

iptables -t nat -I POSTROUTING -o tapX -j SNAT --to yy.yy.yy.yy

where tapX is the virtual device of the openvpn client, if you have only 1 connection, on an endian firewall that device is normally tap2. But you can check it with this command:
ps aux | grep openvpn
and search the connection to your server, there you will see an option like --tap tapX. that's your tap device.

the ip-address yy.yy.yy.yy you determine by checking the ip address assigned to that tap device:

ip addr show tapX
(0000866)
peter-endian   
2008-01-29 19:06   
forgot to mention:
with that solution, you will always see connections coming in through the vpn with the ip address of your vpn endpoint, instead of the extern ip address.

That's sometimes not what you want, but it's the only possibility without changing the default gateway on the vpn endpoints as i mentioned before.
(0000868)
Daloia   
2008-01-30 00:32   
I've tryed the solution above... but for me don't work!
I have done the forwarding on the vpnserver with public ip, i've added the rule in the vpn client machine.. i can see the rule counter go on.. but it doesn't work!