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
    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
Reply
  • 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
Children
No Data