Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 3138 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.
Parents
  • 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
Reply
  • 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
Children
  • 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