Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 3136 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

SNAT-Rule not working in Site-to-Site VPN

ToBu
Hi Community,

I am currently working on a Site-to-Site VPN were I have to to NAT the server, being able to access the remote network using an public IP-address.
Since Keep-Alive is not used for this VPN-connection, I also deactivated Dead Peer detection

The network object included in this configuration consist of:
local VPN-gateway: 217.x.y.z
remote VPN-gateway: 136.x.y.z
Public IP-address: 201.x.y.z


The current configuration of network objects relevant for this Site-to-Site VPN is

SNAT-rule for Site-to-Site VPN-connection
===========================
Traffic source: server in local network (single host)
Traffic service: any
Traffic destination: 136.x.y.z
NAT mode: SNAT (source)
Source:201.x.y.z
Automatic packet filter rule: Yes


IPSec-Connection
===========
Remote gateway: 136.x.y.z
local Interface: 217.x.y.z
Policy: custom Policy (WPA2-PSK)
Auto packet filter: Yes
strict routing: No

In the remote gateway configuration, the VPN ID Type is set to "IP address", but left empty.


The log file produced looks as follows:

2011:04:21-15:06:11 srvfirewall pluto[4248]: listening for IKE messages 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | found lo with address 127.0.0.1 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | found eth0 with address 192.168.x.y 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | found eth1 with address 217.y.z.82 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | found eth1 with address 217.y.z.84 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | found eth1 with address 217.y.z.85 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | found eth2 with address 192.168.0.253 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | found eth4 with address 217.y.z.83 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | found ipsec0 with address x.y.z.82 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | found ipsec1 with address x.y.z.83 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | found tun0 with address 10.x.y.z 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | IP interface tun0 10.x.y.z has no matching ipsec* interface -- ignored 
2011:04:21-15:06:11 srvfirewall pluto[4248]: adding interface ipsec1/eth4 217.x.y.83:500 
2011:04:21-15:06:11 srvfirewall pluto[4248]: adding interface ipsec1/eth4 217.7.173.83:4500 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | IP interface eth2 192.168.x.y has no matching ipsec* interface -- ignored 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | IP interface eth1217.y.z.85 has no matching ipsec* interface -- ignored 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | IP interface eth1217.y.z.84 has no matching ipsec* interface -- ignored 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | IP interface eth0 192.168.x.y has no matching ipsec* interface -- ignored 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | IP interface lo 127.0.0.1 has no matching ipsec* interface -- ignored 
...
2011:04:21-15:06:11 srvfirewall pluto[4248]: loaded shared key for  217.y.z.83 
2011:04:21-15:06:11 srvfirewall pluto[4248]: loaded shared key for 136.x.y.z 217.y.z.83 
2011:04:21-15:06:11 srvfirewall pluto[4248]: loaded shared key for 136.x.y.z 217.y.z.83 
2011:04:21-15:06:11 srvfirewall pluto[4248]: loaded shared key for 136.x.y.z x.y.z.83 
...
2011:04:21-15:06:11 srvfirewall pluto[4248]: | /32===217.x.y.83...136.x.y.z=== 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | ike_life: 86400s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; policy: PSK+ENCRYPT+TUNNEL 
...
2011:04:21-15:06:11 srvfirewall pluto[4248]: | inserting event EVENT_SO_DISCARD, timeout in 0 seconds for #118841 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | Queuing pending Quick Mode with 136.1.1.51 "S_Site2Site-VPN" 
2011:04:21-15:06:11 srvfirewall pluto[4248]: "S_Site2Site-VPN" #118841: initiating Main Mode 
...
2011:04:21-15:06:11 srvfirewall pluto[4248]: | next event EVENT_RETRANSMIT in 10 seconds for #118841 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | *received whack message 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | from whack: got --esp=aes256-sha1 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | alg_info_parse_str() ealg_buf=aes aalg_buf=sha1eklen=256 aklen=0 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | enum_search_prefix () calling enum_search(0x80c4584, "ESP_AES") 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | parser_alg_info_add() ealg_getbyname("aes")=12 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | enum_search_prefix () calling enum_search(0x80c4718, "AUTH_ALGORITHM_HMAC_SHA1") 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | parser_alg_info_add() aalg_getbyname("sha1")=2 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | __alg_info_esp_add() ealg=12 aalg=2 cnt=1 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | esp string values: 12_256-2, 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | from whack: got --ike=aes256-sha-modp1024 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | alg_info_parse_str() ealg_buf=aes aalg_buf=shaeklen=256 aklen=0 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | enum_search_prefix () calling enum_search(0x80c47b8, "OAKLEY_AES") 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | enum_search_ppfixi () calling enum_search(0x80c47b8, "OAKLEY_AES_CBC") 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | parser_alg_info_add() ealg_getbyname("aes")=7 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | parser_alg_info_add() aalg_getbyname("sha")=2 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | enum_search_prefix () calling enum_search(0x80c47f8, "OAKLEY_GROUP_MODP1024") 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | parser_alg_info_add() modp_getbyname("modp1024")=2 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | __alg_info_ike_add() ealg=7 aalg=2 modp_id=2, cnt=1 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | ike string values: 7_256-2-2, 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | alg_info_addref() alg_info->ref_cnt=1 
2011:04:21-15:06:11 srvfirewall pluto[4248]: | alg_info_addref() alg_info->ref_cnt=1 

Nothing whatsoever of the SNAT-rule shows up in the log, so I guess there is something wrong with the way I set this configuration up.

Could anybody give me a hint on howe to troubleshoot this issue?

Thank you very much in advance.

Regards

Tobias


This thread was automatically locked due to age.
  • 0
    Hi, Tobias, I see your solution, but I don't see the problem.  Are you saying that your situation is the following?

    {client on the internet}{public IP on Astaro}{VPN to other site}{other site}{server desired by client}



    If so, then you need a Full NAT at the Astaro so that the {other site} knows to send the server's response through the VPN tunnel instead of directly out over the internet.

    If that's not it, then please supply a diagram or something that makes the networking requirments clear.

    Cheers - Bob

  • 0 in reply to BAlfson
    Hi Bob,

    sorry for my late reply, but I was on holidy around easter.

    The networking requirement is as follows:

    [server on internal network]  [ASG][SNAT-rule to supply public IP as sender's address]  [VPN-Tunnel to other site]  [other site's Firewall]  [destination network at other site]

    Should you need any additional information, please contact me.

    Regards

    Tobias
  • 0
    I still may be confused.  I think I understand that you have an ASG with external IP of 217.x.y.83 connecting via VPN to another firewall with external IP of 136.x.y.z, and that you want to SNAT from 217.x.y.83 - correct?  In that case, I don't think your SNAT solution can work, and, if it could, then the other firewall would need to know how to route traffic back through the tunnel when sending responses to your external IP, else your Astaro's connection tracker would drop the repsonses, I think.

    Why do you want to change the packets to have your external address?  What issue on the other end are you trying to adapt to?

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi Bob,

    the ASG's external interface to be used for the VPN-tunnel gateway's IP-address indeed is 217.x.y.83, however the IP-address to be used for the SNAT is 201.x.y.z

    I use a different IP-address for SNAT since I think using the same IP-address for the VPN-gateway and SNAT is  not supported by the ASG.

    The admins supporting the firewall on the tunnel's remote end have been informed about this configuration, of course.
    The issue I have to adapt to is simply, that the "remote site" just wouldn't accept private IP-addresses to connect into their network due to security policy reasons.
    So, it is not really because of a technical, but more of a political issue, that I have to get this SNAT configuration to work.

    Best regards

    Tobias
  • 0
    Thanks, Tobias, I think I see it now.  On their end, they only have 201.x.y.z included in the tunnel definition as your local network, as you should have on your end.  I don't think you need to add that as an additional address on an interface, but you might need to.

    Your SNAT should be:

    Traffic source: server in local network (single host)
    Traffic service: any
    Traffic destination: {internal IP(s) of the other side, not the external IP of the VPN gateway}

    NAT mode: SNAT (source)
    Source:201.x.y.z

    Automatic packet filter rule: Yes



    If it's not working yet, please post pictures of the 'Remote Gateway' and 'IPsec Connection' definitions.

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi Bob,

    unfortunately, the tunnel is still not coming up; even trying to connect through the tunnel to remote machine does not bring it up.

    I added the rrequested screenshot as attachments to this post. Hoepfully they give some some insight into the post of this matter.

    The objects used in these screenshot are defined as follows:

    ODETTEserver: single host in the ASG's local network
    VPN-FordGWRem: The remote site's gateway, menaing the public IP-address (136.x.y.z)
    VPNFord: The local VPN-gateay's public IP-address (217.x.y.z)


    Best regards

    Tobias
  • 0
    It looks like you have ODETTEserver as your local network, but I think you want {201.x.y.z}.

    Then, you create a NAT rule 'ODETTEserver -> Any {remote networks} SNAT from {201.x.y.z}'.

    Does that work?

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi Bob,

    sorry it took me so long.
    In short: No .it does not work. However the issue is a little bit different this time.

    The error message I get in the log reads "Informational exchange must be encrypted", which obviously has something to do with ISAKMP, however I am at a loss to understand what setting I have to notify to overcome this problem, since I thought that establishing and tearing down a VPN-tunnel always was performed encrypted.

    Regards

    Tobias
  • 0
    Sorry, I've been away for awhile.  I think you need someone to look at your situation.  I can't think of any other questions to ask.  If you have Premium maintenance, Astaro needs to look at this.  If you have Standard maintenance, I think it would be worth paying your reseller to look at your ASG.

    Cheers - Bob