— pissing into the wind

Archive
Juniper

This is a copy/paste from https://forums.he.net/index.php?topic=3194.0.  I’m keeping it here in case that post ever disappears and I need a reference.

This isn’t something people do often, so I figured I would add a post about it (mostly so I can Google it myself in a few years…)
To configure Dynamic DNS (DDNS) updates on your NetScreen/SSG device (may vary slightly between revisions/models):
NOTE: You might also require PING/ICMP Echo Request to be enabled on WAN interface…
By default, DDNS uses HTTPS to connect to update server. You must add the CA certificate that signed the server’s certificate.  For tunnelbroker, connect tohttps://ipv4.tunnelbroker.net/nic/update – you don’t need to login so click cancel if prompted. To display the certificate click (or double-click) on the "padlock" next to "https" in the address bar.
– in Chrome, click "Connection" then "Certificate details"
– in IE, click the padlock then "View certificates" – (IE seems to have issues saving certificates to a file…)
Select the "Certification Path" tab
Double-click the entry immediately above(currently "Starfield Secure Certificate Authority – G2") the default/bottom one (e.g. tunnelbroker.net)
Select "Details" tab
Select "Copy to file"
Next / Base-64 / Browse – pick somewhere you can find it and a name you can remember, e.g. "starfield-2.cer"
Now, go to Web-UI on NS/SSG
Navigate to Objects – Certificates
Select "File: Choose File"
Find the cert you saved previously, OK
Select "Load"
Adding Certificates via CLI:
Not recommended as it requires storing the cert file on a tftp server, but read about it here: http://kb.juniper.net/InfoCenter/index?page=content&id=KB4777
The NS/SSG can now validate the certificate when it connects to update server!
Next, gather your tunnel information.
From https://tunnelbroker.net/ find your tunnel entry
e.g. username-1.tunnel.tserv3.xxx1.ipv6.he.net
copy this hostname somewhere you can find it
Click on the tunnel entry
Click on the Advanced tab
Copy your Update Key somewhere you can find it
Now, the actual DDNS part….
Option #1: Web-UI
In NS/SSG Web-UI, navigate to Network / DNS / DDNS
Take note of any existing entries as you will be prompted for an ID number that is not currently in use…
Select "New"
Enter an unused ID number (1 is fine if you have no existing entries)
Set server type to "dyndns"
Set server name to "ipv4.tunnelbroker.net"
Defaults for update intervals should be fine
Leave "Clear text" unchecked – that is why we added the cert!
Enter your account name in "Username"
Enter your "Update Key" in Password
Leave Agent blank – it will auto-populate with your OS version, unless you want to put something else here
Bind to Interface – Select your WAN/untrust interface your tunnel is on
For "Hostname", enter your tunnel name – e.g. username-1.tunnel.tserv3.xxx1.ipv6.he.net
For Service, leave default of "dyndns"
Select OK!
Option #2: CLI:
get dns ddns  – take note of any existing entries as they must each have a unique ID number
set dns ddns id X server "ipv4.tunnelbroker.net"server-type dyndns
set dns ddns id X username USERNAME password UPDATEKEY
set dns ddns id X src-interface ethernet0/0 host-name username-1.tunnel.tserv3.xxx1.ipv6.he.net
set dns ddns enable
To view status:
-> get dns ddns
status: enable  usage: 1/8
id type   state server          username   interface  nextupdate   lastresp
——————————————————————————–
1 dyndns     1 ipv4.tunnelbrok username   eth0/0     6d;23:24:00  nochg
To view detailed status:
-> get dns ddns id X
Id:                     1
State:                  Init
Socket:                 -1
Type:                   dyndns
Server:                 ipv4.tunnelbroker.net
Clear-text:             no
Refresh-int:            7 days 0 hours 0 minutes 0 seconds
Min-update-int:         1 hours 0 minutes 0 seconds
Next-update:            6 days 23 hours 24 minutes 0 seconds
Username:               username
Password:               **********
Agent:                  Netscreen-6.X-00000
Src-interface:          ethernet0/0
Host-name:              username-1.tunnel.tserv3.xxx1.ipv6.he.net (dyndns)
Last-response:          nochg
Last-response-ip:       0.0.0.0
Last-Updated:           before 36 minutes 8 seconds
Counters
——————————————————————————–
Successful updates:     3
Failed updates:         0
Server lookup failures: 5
Socket creation errors: 0
Socket connect errors:  3
Socket send errors:     0
Update retries:         0
To debug / troubleshoot:
From CLI:
Cancel debugging / clear buffer:
-> undebug all   (or press <ESC>)
-> clear dbuf
Enable DDNS debugs:
-> debug dns ddns
View dbuf:
-> get dbuf stream
Errors that show DNS is working:
ddns: server ipv4.tunnelbroker.net resolved to 64.62.200.2
Errors that show SSL issue:
DDNS: connect error
socket creation failed
Successful update:
ddns: server ipv4.tunnelbroker.net resolved to 64.62.200.2
GET /nic/update?system=dyndns&hostname=username-1.tunnel.tserv3.xxx1.ipv6.he.net&myip=XXX.XXX.XXX.XXX&wildcard=OFF&mx=mail.exchanger.ext&backmx=NO&offline=NO HTTP/1.0
Accept: text/html;*.*;
Host: ipv4.tunnelbroker.net
….
nochg XXX.XXX.XXX.XXX
….
ddns: succesfully updated DYNDNS server
The "nochg" means the updated IP matches the existing one, so "no change".
Don’t forget to cancel debugging with "undebug all" or pressing "<ESC>"
Brian

Read More

… My dad changed ISPs and took the SSG5 I gave him offline.  I had to disable the VPN on my side because it was spamming the logs.  If I ever need to re-enable it, all I need to do is bind it to tunnel.1 and re-enable monitor, optimized, and rekey.

Read More

Setting up VPNs is always a PIA, but Juniper really dumbs it down and I have to say really spoiled me.  So when it came time to setup another VPN with a partner who is running an ASA, I had to shake off the rust and think of what could go wrong.  Most of the time I set up tunnels with non-Juniper devices, it ends up being a wrong proxy-id on either side.  You can usually tell this when you see “DOI 1 18 INVALID-ID-INFORMATION” or “No policy exists for the proxy ID: local(local ip/netmask/0/0) remote(remote ip/netmask/0/0)”.   ScreenOS derives the proxy-id from the tunnel, so I normally don’t worry about setting this up, but of course it only works as designed when you connect to other ScreenOS devices.  I don’t know if the SRX platform behaves the same way since it’s running JunOS.  I caught this error message and we managed to get the tunnel going, but no traffic was passing through.  Being a Friday night and this not being a critical issue at the moment, both sides decided to come back to it later.

I have a couple Cisco routers and Juniper SSGs at home for a lab.  I recently picked up an ASA 5505 off of eBay as well and decided to give the configuration on both sides a try to figure out what is going wrong.  Beyond setting up AAA, ntp, and the rest of the management stuff, I have not really had time to do anything with the ASA.  I have experience with IOS from a router and switch perspective, but I’ve never touched PIX.  All of my firewall experience is with Fortinet, ScreenOS, and whatever linux distros I’ve tried (Astaro comes to mind).

Cisco’s documentation being as awesome as it is, that is the first place I went to figure out what to do:

I’m not one to use a GUI with Cisco devices, so I went through some configuration examples and the cli configuration guide as a first pass to get the tunnel up and running.  I managed to do this, but I couldn’t connect anything beyond the inside interfaces on either gateway and only gateway to gateway.

So I wiped the ACLs and crypto config I put in and fired up ASDM.  I used the IPSEC VPN Wizard and kept flipping back to my console to see what changes it was making.  One of the first things that caught my eye was the option to “Enable inbound IPSEC sessions to bypass interface access list.”  Not having experience with setting up Cisco VPNs before, I thought, “Why on God’s green Earth would I not have policies to control that traffic?” Yes, it’s implied that I trust the other side to some degree if I’m setting up a VPN tunnel, but I still want fine grain control of the communication.  That checkbox leaves the default setting “sysopt connection permit-vpn” intact.  This does exactly what the description says on the checkbox.  Without it, you have to setup multiple ACLs to get tunnel traffic working properly because the traffic terminates on the outside interface of the ASA.

gp01

I setup a working VPN with and without that box checked, and I decided to go with it checked.  As it turns out, you can use filters on the connection group policy to control exactly what passes through the tunnel.  In this basic lab without the box checked, I had to add an additional 3 policies to get traffic moving through the tunnel.  This might not seem like a hassle, but this is just a lab with a single site to site.  Extrapolate that complexity when you start adding multiple sites.  There may be some scenarios where filters just won’t be sufficient, but for what I need to do at work, they will accomplish the task.

gp02

Excerpt from Troubleshooting Guide:

Note: If you do not wish to use the sysopt connection command, then you must explicitly permit the required traffic, which is interesting traffic from source to destination, for example, from LAN of remote device to LAN of local device and “UDP port 500” for outside interface of remote device to outside interface of local device, in outside ACL.

http://networking-forum.com/viewtopic.php?f=35&t=3310

According to chapter 21 of The Complete Cisco VPN Configuration Guide, the way to do what I am asking is to write manual access lists to permit ipsec/isakmp traffic.

Using this method, one must manually write access lists to permit all ports used by ipsec/isakmp components to allow this traffic into a firewall. This method makes it so packets are checked against access lists twice: once when coming in as ipsec traffic, and again once decrypted as plaintext packets. This allows one to match only desired traffic using the second, more stringent access list.

The alternative is using the “sysopt connection permit-vpn” command. This is also known as ACL bypassing, hence, you cannot restrict traffic further, since the access lists are written for you using this command.

Another method (usable only for 7.0 and higher) is using the “sysopt connection permit-vpn” command on an outside interface, and writing more restrictive access lists outgoing on an inside interface. This method enables one to allow all ipsec/isakmp traffic into the firewall while restricting where the traffic can go from there.

The second thing that caught my eye was a NAT policy that gets added:  nat (any,any) source static local local destination static remote remote.  This command makes no sense to me, and I most of the online research I did regarding NAT had a different syntax.  Cisco changed the NAT syntax in 8.3.  Prior to, it was the same as PIX.

Again, Juniper just completely dumbs this down and I never had to configure anything like this.  I’m not a big fan of any-any policies, so I’m going to do some further research on tightening this down later.

For now, here is the setup and working configs for an SSG5 to ASA5505 VPN with and without sysopt enabled.

vpn

Configs:
ASA sysopt
ASA no sysopt
SSG

Read More