Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 3542 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

NAT/Masq traffic destined for 172.16.0.2 (DMZ) to go to 192.168.0.2 (LAN) port 1433

markcasey
I've been experimenting all morning and i've yet to get it working.

In DNAT/SNAT I have configured the following:

Traffic source: DMZ (Network) - 172.16.0.0/24
Traffic service: MS SQL
Traffic destination: DMZ SQL Server - 172.16.0.2

NAT Mode: DNAT

Destination LAN SQL Server - 192.168.0.2
Destination Service: MS SQL


What am I missing?

Essentially here's how it works, I have a webserver in the dmz (172.16.0.1) I want the web server to access the SQL server which is in the lan with an ip address of 192.168.0.2. I want to mask the address so when the webserver connects to the sql server it connects to 172.16.0.2 which nats the traffic to 192.168.0.2.

What have I missed?


This thread was automatically locked due to age.
Parents
  • 0
    Mark, do you have packet filter rules to allow the traffic in both directions?

    You might be better off with a policy route, but I haven't used them enough to know the gotchas.

    Anyway, I think I see your error.  You don't need a separate DMZ IP for the SQL server; just use the Astaro DMZ interface.

    Say you have the following interfaces defined on the Astaro:

    External:
    Internal: 192.168.0.1 255.255.255.0
    DMZ: 172.16.0.1 255.255.255.0


    The DNAT rule should be 

    Traffic selector: DMZ (Network) -> SQL -> DMZ (Address)
    Destination translation: SQL Server


    Good luck - Bob
  • 0 in reply to BAlfson
    Mark, do you have packet filter rules to allow the traffic in both directions?

    You might be better off with a policy route, but I haven't used them enough to know the gotchas.

    Anyway, I think I see your error.  You don't need a separate DMZ IP for the SQL server; just use the Astaro DMZ interface.

    Say you have the following interfaces defined on the Astaro:

    External:
    Internal: 192.168.0.1 255.255.255.0
    DMZ: 172.16.0.1 255.255.255.0


    The DNAT rule should be 

    Traffic selector: DMZ (Network) -> SQL -> DMZ (Address)
    Destination translation: SQL Server


    Good luck - Bob


    That doesn't seem to work.

    I can already get it so for example I can access 192.168.0.2 from the DMZ.

    Traffic selector: Int Web Server (172.16.0.1) -> MS SQL -> LAN SQL Server (192.168.0.2)
    Destination translation: LAN SQL Server (192.168.0.2)


    The problem is that when the web server connects to the sql server it needs to be the ip address 172.16.0.2.

    It isn't just SQL but for the moment I can base the other stuff on the SQL one when it works.

    The reason it needs this is because we have some bespoke software on our web server that we can't change the settings without paying a company x amount of money, even if it's just 5 minutes of work. Otherwise we break the contract.
  • 0 in reply to markcasey
    OK, I'm not sure I understand.

    Which is it?

    • An app in the SQL Server is hard-coded to see the webserver at 172.16.0.2, and it's the SQL Server that wants to post stuff to the webserver. (If so, then maybe SNAT instead of DNAT.)
    • An app in the SQL Server is hard-coded to ignore messages from anything other than 172.16.0.2, and the webserver is querying the SQL Server for data.


    This doesn't make sense to me:
    Traffic selector: Int Web Server (172.16.0.1) -> MS SQL -> LAN SQL Server (192.168.0.2)
    Destination translation: LAN SQL Server (192.168.0.2)

    Is it the webserver that has to appear as 172.16.0.2, or the SQL Server?  172.16.0.1 and 192.168.0.2 aren't on the same subnet, so, absent a route, the traffic selector doesn't make sense.  The destination translation should be different from the destination in the traffic selector.

    We're getting closer.

    Cheers - Bob
  • 0 in reply to BAlfson
    OK, I'm not sure I understand.

    Which is it?

    • An app in the SQL Server is hard-coded to see the webserver at 172.16.0.2, and it's the SQL Server that wants to post stuff to the webserver. (If so, then maybe SNAT instead of DNAT.)
    • An app in the SQL Server is hard-coded to ignore messages from anything other than 172.16.0.2, and the webserver is querying the SQL Server for data.


    This doesn't make sense to me:

    Is it the webserver that has to appear as 172.16.0.2, or the SQL Server?  172.16.0.1 and 192.168.0.2 aren't on the same subnet, so, absent a route, the traffic selector doesn't make sense.  The destination translation should be different from the destination in the traffic selector.

    We're getting closer.

    Cheers - Bob


    It is an app on the web server that is hard coded to connect to 172.16.0.2.

    So, I need the web server (172.16.0.1) to connect to the sql server (192.168.0.2).

    But when the web server connects to the sql server it needs to see the sql server as 172.16.0.2 rather than 192.168.0.2.
Reply
  • 0 in reply to BAlfson
    OK, I'm not sure I understand.

    Which is it?

    • An app in the SQL Server is hard-coded to see the webserver at 172.16.0.2, and it's the SQL Server that wants to post stuff to the webserver. (If so, then maybe SNAT instead of DNAT.)
    • An app in the SQL Server is hard-coded to ignore messages from anything other than 172.16.0.2, and the webserver is querying the SQL Server for data.


    This doesn't make sense to me:

    Is it the webserver that has to appear as 172.16.0.2, or the SQL Server?  172.16.0.1 and 192.168.0.2 aren't on the same subnet, so, absent a route, the traffic selector doesn't make sense.  The destination translation should be different from the destination in the traffic selector.

    We're getting closer.

    Cheers - Bob


    It is an app on the web server that is hard coded to connect to 172.16.0.2.

    So, I need the web server (172.16.0.1) to connect to the sql server (192.168.0.2).

    But when the web server connects to the sql server it needs to see the sql server as 172.16.0.2 rather than 192.168.0.2.
Children
  • 0 in reply to markcasey
    Define an additional interface, 172.16.0.2, on the DMZ interface; let's call it 'SQL Phantom'

    Create a DNAT rule:
    Traffic selector: Webserver -> SQL -> SQL Phantom
    Destination Translation: SQL Server

    Packet Filter to allow:
    DMZ (Network) -> SQL -> SQL Server

    Yours - Bob
    PS This is almost identical to my original suggestion if the address of the Astaro's DMZ interface had been 172.16.0.2
  • 0 in reply to BAlfson
    Define an additional interface, 172.16.0.2, on the DMZ interface; let's call it 'SQL Phantom'

    Create a DNAT rule:
    Traffic selector: Webserver -> SQL -> SQL Phantom
    Destination Translation: SQL Server

    Packet Filter to allow:
    DMZ (Network) -> SQL -> SQL Server

    Yours - Bob
    PS This is almost identical to my original suggestion if the address of the Astaro's DMZ interface had been 172.16.0.2


    Nope, doesn't work. At the moment for testing I'm using http rather than SQL since it's much easier to tell whether it's working or not.

    Sorry for the short reply, got the pc connected to the firewall which isn't connected to the Internet. Using my iPhone for this post.


    EDIT: Any more ideas? I've been pulling my hair out trying to get this working. It's intensely frustrating.

    Edit2: Got it working!

    EDIT3: Essentially all I needed to do was what I was doing before and what you mentioned in your post above BAlfson, but with one change.

    I went into Network / Interface / Additional Addresses and added 172.16.0.2/32 on interface dmz and voila! It works.  [:)]
  • 0 in reply to markcasey
    Yes, that is correct.  I'm sorry I wasn't clearer about that.

    Great! - Bob