Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 2 subscribers
  • Views 1781 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DNAT to host behind IPSec-Tunnel

DiePlage
Hello Folks,

I try to create a DNAT rules that forwards incoming traffic to a host on the remote-siede of an IPSec tunnel. This is the setup:

ASG1:
External: 111.111.111.2/29
internal: 192.168.1.1/24

ASG2:
External: 111.111.222.2/29
internal: 192.168.2.1/24
internal Webserver 192.168.2.10

LAN ASG1 & LAN ASG2 are connected with an IPSec-tunnel.
Unfortunately there are no free external IPs left at ASG2.

So my idea was to add an extra external IP to ASG1's external Interface say 111.111.111.3 and create a DNAT rule like this: any -> 111.111.111.3:80tcp DNAT 192.168.2.10:80tcp

I can ping 192.168.2.10 from ASG1 and I can reach the Webserver from LAN ASG1.
If I try to access http://111.111.111.3 I can see the DNAT Rule allowing traffic to 111.111.111.3:80 and a packetfilter rule allowing traffic to 192.168.2.10:80

However, I cannot reach the webserver and there are no dropped or allowed packets in ASG2's packetfilter log (ASG2 is set to log every packet).

From this observation I suppose that no traffic reaches ASG2 and I must have made a mistake in my thinking.

Thank you for any hints!

Cheers!


This thread was automatically locked due to age.
Parents
  • 0
    Exactly.  I have a client in Omaha that called in a panic one day because they had an expensive consultant in and they couldn't solve the problem.  Their explanation to me was hard to follow since English was not the consultant's first language.  Finally, I understood where everything was, and just imagined I was a packet and what I needed to get where I needed to go.

    With just a DNAT in ASG1, you can get the packet to the webserver behind ASG2.  The problem is that the webserver responds to the "Source IP" in the packet, a public IP, and ASG2 routes that directly into the internet from its External interface, so the response gets killed after it leaves.

    In order for the packet to go back through the tunnel, there has to be an IP that exists for the tunnel, as you said, and that's supplied by the Full NAT.  When the response from the webserver arrives back at the address on ASG1, the Astaro connection tracker handles sending the packet back to the originating IP.  I don't think there's any other solution.

    Cheers - Bob
Reply
  • 0
    Exactly.  I have a client in Omaha that called in a panic one day because they had an expensive consultant in and they couldn't solve the problem.  Their explanation to me was hard to follow since English was not the consultant's first language.  Finally, I understood where everything was, and just imagined I was a packet and what I needed to get where I needed to go.

    With just a DNAT in ASG1, you can get the packet to the webserver behind ASG2.  The problem is that the webserver responds to the "Source IP" in the packet, a public IP, and ASG2 routes that directly into the internet from its External interface, so the response gets killed after it leaves.

    In order for the packet to go back through the tunnel, there has to be an IP that exists for the tunnel, as you said, and that's supplied by the Full NAT.  When the response from the webserver arrives back at the address on ASG1, the Astaro connection tracker handles sending the packet back to the originating IP.  I don't think there's any other solution.

    Cheers - Bob
Children
No Data