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

IPSec VPN First Timer

bensley
Hey Guys n Gals,

Im setting up an IPSec VPN Tunnel between an ASG 120 and a Watchguard Firebox SOHO 6, I have seen several people around the forums speak of this set up so it must be possible but I can't get it to work.

ASG120 Setup:
Remote Gateway>
Gateway Type: Initiate Connection
Gateway 192.168.1.10
Authentication Type: Preshared Key
Remote Networks: (A network defined as the remote class C network 192.168.111.0/24)
IPSec Connection:
Remote Gateway: The above gateway!
Local Interface: Internal
Local Networks: Internal Network
Auto Packet Filter: Ticked
Policy: My Customer Policy

My Custom Policy>
IKE encryption algorithm: DES
IKE authentication algorithm: MD5
IKE SA lifetime: 7800
IKE DH group: Group 1
IPSec encryption algorithm: DES
IPSec authentication algorithm: MD5
IPSec SA lifetime: 3600
IPSec PFS group: None

WatchGuard Firebox SOHO 6 Manual VPN Settings:
Phase 1>
Mode: Main Mode
Remote IP: 192.168.1.254 (ASG 120)
Local ID: 192.168.1.10
Remote ID: 192.168.1.254
Authentication: MD5-HMAC
Encryption: DES-CBC
Negotiation expiration in kilobytes: 0
Negotiation expiration in house: 24
DH Group: 1
Generate IKE Keep Alive Messages: Ticked

Phase 2>
Authentication: MD5-HMAC
Encryption: DES-CBC
Key expiration in kilobytes: 8192
Key expiration on hours: 24
Local Network: Local LAN Range
Remote Network: ASG120 LAN Rage

The problem I'm facing is that my ASG120 isn't exactly giving any specific error for not connecting, the live log is here:
pastebin - collaborative debugging tool

The WatchGuard is logging the following error:
Main Mode processing failed
Unable to fill local ID
Unable to find gw by hisid
Rejecting peer XAUTH request: not configured

Then the following line is repeated every so ofton on the WatchGuard:
Rejecting peer XAUTH request: not configured

I'm not sure looking at the ASG Live Log what is actually the problem!


This thread was automatically locked due to age.
  • 0
    Strange Ip adresses for a VPn but I suppose this is due to a lab environment?
     
    Well, looking at the log (great, you enabled ALL debugging options, didn´t you...grrr :-) I see the following:
     
    2009:10:19-16:18:58 AdminFirewall pluto[6596]: | sending 252 bytes for main_outI1 through eth0 to 192.168.1.10:500
    2009:10:19-16:18:58 AdminFirewall pluto[6596]: | *received 100 bytes from 192.168.1.10:500 on eth0
    2009:10:19-16:18:58 AdminFirewall pluto[6596]: | sending 188 bytes for STATE_MAIN_I1 through eth0 to 192.168.1.10:500:
    2009:10:19-16:18:59 AdminFirewall pluto[6596]: | *received 192 bytes from 192.168.1.10:500 on eth0
    2009:10:19-16:18:59 AdminFirewall pluto[6596]: | sending 60 bytes for STATE_MAIN_I2 through eth0 to 192.168.1.10:4500:
    2009:10:19-16:19:09 AdminFirewall pluto[6596]: | sending 60 bytes for EVENT_RETRANSMIT through eth0 to 192.168.1.10:4500:
    2009:10:19-16:19:09 AdminFirewall pluto[6596]: | *received 192 bytes from 192.168.1.10:500 on eth0
    2009:10:19-16:19:21 AdminFirewall pluto[6596]: | *received 192 bytes from 192.168.1.10:500 on eth0
    2009:10:19-16:19:29 AdminFirewall pluto[6596]: | sending 60 bytes for EVENT_RETRANSMIT through eth0 to 192.168.1.10:4500:
    2009:10:19-16:19:33 AdminFirewall pluto[6596]: | *received 192 bytes from 192.168.1.10:500 on eth0
    2009:10:19-16:19:45 AdminFirewall pluto[6596]: | *received 192 bytes from 192.168.1.10:500 on eth0
    2009:10:19-16:19:57 AdminFirewall pluto[6596]: | *received 192 bytes from 192.168.1.10:500 on eth0
    2009:10:19-16:20:09 AdminFirewall pluto[6596]: | sending 252 bytes for main_outI1 through eth0 to 192.168.1.10:4500:
    2009:10:19-16:20:19 AdminFirewall pluto[6596]: | sending 252 bytes for EVENT_RETRANSMIT through eth0 to 192.168.1.10:4500:
     
    This means the ASG detects a NAT device between itself and the Watchguard and changes to port 4500 (UDP-encapsulation for ESP packets).
    Look here: 
    2009:10:19-16:18:59 AdminFirewall pluto[6596]: "S_Unknown Object" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: both are NATed

    The Watchguard still sends out packets on port 500 (IKE).
     
    For me, on the Astaro side all looks good, but the Watchgaurd seems to insist on still sending IKE packets although the inititial IKE phase should be over already.
     
    Can you check whether udp packets with port 4500 can travel from the ASG to the Watchguard and vice versa? any firewall between the perhaps blocking these packets?
  • 0 in reply to Ölm
    Hey guys, Watchguard's Implementation of IPSEC is flawed (I've even had them admit this)... If you have NAT-T enabled on your Astaro, Disable it.
  • 0
    Hey Guys;

    Thanks for your fast responses. I have my VPN working now. It was a combination of having NAT-T Enabled on the Astaro and a misconfiguration of the Local Interface on the Astaro which was set to the Internal Network but should be the External Network.

    Thanks for your help guys its greatly appreciated. Hopefully seeing as I think I am the only person to dump my full set up in a thread on this forum someone else will benefit from this.
  • 0
    Observations about the choice of a PSK instead of a cert...

    The Astaro can have only one PSK used for "Respond only" connections (yes, not your case).  That means, for example, if you use a PSK with 'L2TP over IPsec' Remote Access, you must use the same PSK with any 'Respond only' IPsec Site-to-Site connection.

    A Site-to-Site with a certificate is pretty much "set it and forget it" from a security point of view.  A PSK should be changed regularly.

    Cheers - Bob
  • 0 in reply to BAlfson
    Glad to hear we could help... I dunno why Watchguard won't fix their NAT-T implementation, but it's enabled me to sell more Astaro units! The customer that I had that had this problem initially wanted to be able to use remote IPSEC clients that would be behind a NAT... well, NAT-T on the Astaro is a global setting, affecting both mobile and site-to-site users.  Since their core firewall was an Astaro, we ended up dumping the Watchguards (I didn't sell them to them, they were old legacy units), that coupled with the poor support from Watchguard sealed the deal.