Juniper SRX: IPSec VPN sourcing from loopback interface in a VRF

Probably not an overly common setup but you’ll inevitably become frustrated if you try it. As per this Juniper PR, it’s necessary to put your loopback interface and your external interface(s) in the same security zone. You still need that if you are sourcing from a loopback interface in a routing-instance however it doesn’t quite resolve the issue.

If you enable enough logging, you’ll see that the phase 1 (UDP) works fine but the phase 2 (ESP) gets blocked. If you look at flow logs, the following is the important bit:

  1. CID-1:THREAD_ID-05:RT:flow_first_policy_search: policy search from zone edge-> zone edge (0x0,0x11941194,0x1194)
  2. CID-1:THREAD_ID-05:RT: packet dropped, denied by policy

This says that it’s looking for a policy that permits ESP within the “edge” zone. In my case, “edge” is the name of the security zone that contains the external interfaces and the loopback interface.

The solution is to add a security policy from-zone edge to-zone edge which allows ESP. It looks like this:

  1. phil@be-fw-03# show security policies from-zone edge to-zone edge
  2. policy a_esp {
  3. match {
  4. source-address any;
  5. destination-address any;
  6. application esp;
  7. }
  8. then {
  9. permit;
  10. }
  11. }
  13. {primary:node0}[edit]
  14. phil@be-fw-03# show applications application esp
  15. term t1 protocol esp;

I couldn’t see a JunOS inbuilt policy for esp so I created the applicationesp as shown above.

If you’re using NAT Traversal with your VPN, it’s possible you’ll need to allow more stuff in your application. That might look like this:

  1. term t1 protocol udp source-port 500 destination-port 500;
  2. term t2 protocol udp source-port 4500 destination-port 4500;
  3. term t3 protocol esp;

Juniper JunOS: Difference between rib-groups and instance-import

Both rib-groups and instance-import allow you to selectively (or non-selectively) import routes into one VRF from another. I won’t go into detail of the syntax and usage of these two as Matt Dinham does it extremely well in his blog post.

However, it’s important to document the fundamental difference between the two. In essence, instance-import works on FIB routes and rib-groups work on RIB routes. That is to say that instance-import will only export the currently active route(s) from the source VRF whereas rib-groups will export all routes from the target VRF.

Let’s say, for example, you wanted to create a VRF which contained a copy of all of the routes from your transit providers and none of the routes from your direct peers. Because instance-import only imports currently active routes from the source table, it is unsuitable for the task at hand because it’s probable that many of your transit routes are inactive in favour of the direct peerings.

Juniper MX204 – Enabling 100G ports

This was far more difficult than it should be so it’s worth writing down…

First, check the Juniper Port Checker to ensure that the port configuration you want is supported. In my case, I wanted 2x 100G (QSFP28), 2x 40G (QSFP+) and 8x 10G (SFP+). You now need to configure all of those ports explicitly:

  1. chassis {
  2. fpc 0 {
  3. pic 0 {
  4. port 0 {
  5. speed 100g;
  6. }
  7. port 1 {
  8. speed 100g;
  9. }
  10. port 2 {
  11. speed 40g;
  12. }
  13. port 3 {
  14. speed 40g;
  15. }
  16. }
  17. pic 1 {
  18. port 0 {
  19. speed 10g;
  20. }
  21. port 1 {
  22. speed 10g;
  23. }
  24. port 2 {
  25. speed 10g;
  26. }
  27. port 3 {
  28. speed 10g;
  29. }
  30. port 4 {
  31. speed 10g;
  32. }
  33. port 5 {
  34. speed 10g;
  35. }
  36. port 6 {
  37. speed 10g;
  38. }
  39. port 7 {
  40. speed 10g;
  41. }
  42. }
  43. }
  44. }

Now, you need to restart both PICs on FPC 0. Naturally, don’t do this in production or it’ll make a mess. First, bring the PICs offline:

  1. request chassis pic pic-slot 0 fpc-slot 0 offline
  2. request chassis pic pic-slot 1 fpc-slot 0 offline

Now bring them back online (1G/10G ports first).

  1. request chassis pic pic-slot 1 fpc-slot 0 online
  2. request chassis pic pic-slot 0 fpc-slot 0 online

JunOS error: In routing-instance default-switch interface ae3.0 has vlan and vxlan mixed which is not supported

You might see this error when using VXLAN on Juniper kit after you set an interface to be a member of “all” VLANs. This is because “all” includes VLAN 1. Per this documentation, you can’t actually use VLAN 1 with VXLAN but you must map it to a VNI. For example:

  1. /* You need to map VLAN 1 to a VNI else you can't use `vlan members all` on interfaces - DO NOT USE THIS VLAN */
  2. VLAN001 {
  3. vlan-id 1;
  4. vxlan {
  5. vni 1;
  6. }
  7. }

Set syntax is:

  1. set vlans VLAN001 vlan-id 1 vxlan vni 1
Tags: , , ,

Juniper SRX – Upgrading JunOS from USB

There’s a few ways to do this. Here’s the easiest:

First, format your USB drive as fat32. Download the compressed image from Juniper (e.g. junos-srxsme-15.1X49-D80.4-domestic.tgz) and load it onto the USB drive.

Whilst logged into the SRX’s console, plug in the USB drive. You’ll see something like the below:

  1. umass1: TOSHIBA TransMemory, rev 2.00/1.00, addr 2
  2. da1 at umass-sim1 bus 1 target 0 lun 0
  3. da1: <TOSHIBA TransMemory 1.00> Removable Direct Access SCSI-4 device
  4. da1: 40.000MB/s transfers
  5. da1: 7400MB (15155200 512 byte sectors: 255H 63S/T 943C)

This tells you that the USB drive is available at /dev/da1. Assuming your drive has a single partition, that means the filesystem will be at /dev/da1.

Jump into the FreeBSD shell:

  1. start shell

Create a directory and mount the USB drive to it:

  1. mkdir /var/tmp/usb/
  2. mount_msdosfs /dev/da1 /var/tmp/usb/

Check that your JunOS image is present on the mount:

  1. root@% ls -1 /var/tmp/usb/
  2. junos-srxsme-15.1X49-D80.4-domestic.tgz

Jump back to the main JunOS console:

  1. exit

Install the image:

  1. request system software add no-copy no-validate /var/tmp/usb/junos-srxsme-15.1X49-D80.4-domestic.tgz

Reboot your device:

  1. request system reboot in 0

Once rebooted, sanity check your new install. If all is ok, you need to copy the JunOS image to the backup partition else if your SRX ever fails to boot then it will boot into your old JunOS:

  1. request system snapshot slice alternate

Once done, you can check it:

  1. root> show system software
  2. Information for junos:
  4. Comment:
  5. JUNOS Software Release [15.1X49-D80.4]
  7. root> show system software backup
  8. Backup JUNOS package information:
  9. File name: /altroot/cf/packages/junos-15.1X49-D80.4-domestic
  10. File size: 249978054

And that’s it.