Spam Protection for your WordPress Blog

Hey everyone,

With the kind of coverage your blogs might get if you happen to run them, you might run into spam issues. I certainly have with over 100,000 hits in the last few months. Best plugin I’ve found for this is CleanTalk for WordPress. I’d definitely recommend installing it and seeing what it might be able to do for your website. It costs peanuts per year and can preemptively protect your server before the spammer hits comments.php or what ever the thingy is :)

https://cleantalk.org

Cheers

P

(ps, this isn’t spam, i actually wrote this lol, promise)

Junos OS DHCP in VRFs

As more users look to consolidate systems and networking resources in my current job, there has been an increasing need to use VRFs for specific application. This time, I’m not talking about VRFs in the MPLS sense, just “VRF lite” or virtual-rotuer in Junos. Fairly common practice on shared managed infrastructure such as firewalls or VPN concentrators is running DHCP services or bootp/dhcp forwarding inside virtual routers. Until now Junos really hasn’t had a way of doing this in a clean fashion unlike IOS which makes this process extremely simple. Before the release of 12.1 as far as I’m aware, there was no way of using the built in dhcp process to assign address/attributes to any network that wasn’t in the master routing instance. I managed to find a work around via a kb artcile for this which i’ll demonstrate below, and let me be clear, I am not even close to a fan of it.

**Note I use VRF and virtual-router interchangeably here**

Scenario: “guest” wireless network separate from all corporate resources using an SRX as a switch/firewall/router on a stick.

set security policies from-zone guest to-zone internet policy guest-internet-access match source-address 192.168.4.0/24
set security policies from-zone guest to-zone internet policy guest-internet-access match destination-address any
set security policies from-zone guest to-zone internet policy guest-internet-access match application any
set security policies from-zone guest to-zone internet policy guest-internet-access then permit

set vlans guest vlan-id 30
set vlans guest interface ge-0/0/15.0
set vlans guest l3-interface vlan.30

set interfaces vlan unit 30 description "Guest Internet access"
set interfaces vlan unit 30 family inet address 192.168.4.1/24

set routing-instances guest instance-type virtual-router
set routing-instances guest interface vlan.30
set routing-instances guest routing-options static route 0.0.0.0/0 next-hop *internet gateway*
set routing-instances guest routing-options instance-import inet.0-to-guest

set system services dhcp pool 192.168.1.0/24 address-range low 192.168.4.100
set system services dhcp pool 192.168.1.0/24 address-range high 192.168.4.200
set system services dhcp pool 192.168.1.0/24 name-server 8.8.8.8
set system services dhcp pool 192.168.1.0/24 router 192.168.4.1

set security zones security-zone guest address-book address 192.168.4.0/24 192.168.4.0/24
set security zones security-zone guest host-inbound-traffic system-services ping
set security zones security-zone guest host-inbound-traffic system-services traceroute
set security zones security-zone guest interfaces vlan.30 host-inbound-traffic system-services dhcp

This is a very basic security and interface configuration, however if you’ve ever played around with the systems services hierarchy, you’ll notice there ins’t a VRF option like there is in IOS, for example:

ip dhcp pool GUEST_DHCP
   vrf VPN
   network 192.168.2.0 255.255.255.0
   dns-server 202.37.101.1 202.37.101.2 
   default-router 192.168.2.1 
   class GUEST_DHCP
      address range 192.168.2.10 192.168.2.30

From this point onwards, I essentially have to kick into troubleshooting mode to see what the firewall is doing with the dhcp messages from clients wanting an address. Here I’ve setup some simple traceoptions to output to file.

perrin@srx_nz> show log dhcp-debug              
Jun 18 09:47:27 received packet from 0.0.0.0 port 68 interface vlan.30 routing instance guest
Jun 18 09:47:27 packet from 0.0.0.0 discarded: not default routing instance
Jun 18 09:47:28 received packet from 0.0.0.0 port 68 interface vlan.30 routing instance guest
Jun 18 09:47:28 packet from 0.0.0.0 discarded: not default routing instance
Jun 18 09:47:30 received packet from 0.0.0.0 port 68 interface vlan.30 routing instance guest

As you can see, the router is actually dropping the dhcp requests! Pre 12.1 I’m only aware of this one way to “fix” this thanks to the juniper KB articles. If your running 12.1 and on, stay with me, I have the proper solution next!

Juniper recommends getting around this problem by installing a firewall filter on the terminating interface that captures only DHCP traffic on UDP 67 and 68 and allows this into the master routing instance, then, places all other traffic into the guest vrf which we have configured. You also move the interface out of the VRF and into the master RI as well!!

set firewall family inet filter guest-dhcp term dhcp-to-inet.0 from protocol udp 
set firewall family inet filter guest-dhcp term dhcp-to-inet.0 from port 68
set firewall family inet filter guest-dhcp term dhcp-to-inet.0 from port 67
set firewall family inet filter guest-dhcp term dhcp-to-inet.0 then count dhcp-packet
set firewall family inet filter guest-dhcp term dhcp-to-inet.0 then accept 
set firewall family inet filter guest-dhcp term any then routing-instance test 
!
delete routing-instances guest interface vlan.30
!
set interfaces vlan unit 30 family inet filter input guest-dhcp

Because you have moved the interface out of the VRF and back into inet.0 but you are still placing traffic into the VRF with the firewall filter. You have to create a virtual-router import/export policy so the too tables can talk to each other. (I will do a full post on doing this inside virtual-routers in another video)

set routing-instances VVisitor routing-options instance-import inet.0-to-guest
!
set policy-options policy-statement inet.0-to-guest term 1 from protocol static
set policy-options policy-statement inet.0-to-guest term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement inet.0-to-guest term 1 then accept
set policy-options policy-statement inet.0-to-guest from instance master
set policy-options policy-statement inet.0-to-guest then reject
!
set routing-options static route 192.168.4.0/24 next-table guest.inet.0
!
perrin@srx_nz> show route 192.168.4.0/24   

inet.0: 73 destinations, 74 routes (73 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.4.0/24     *[Static/5] 5d 09:10:15
                      to table guest.inet.0


perrin@srx_nz> show route 0.0.0.0 table guest 

guest.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 5d 09:10:44
                    > to *nexthop* via ge-0/0/1.0

With this complete, check the dhcp log file to see if dhcp traffic is being correctly processed by the interface.

Jun 18 12:06:12 Reading pools
Jun 18 12:06:12 Found a pool configuration for 192.168.4.0/24
Jun 18 12:06:12 -- looking for pool with subnet 192.168.4.0, prefix length 24, including shadowed
Jun 18 12:06:12 adding child `Pool' scope 0x57b000 to `Global' scope 0x576400
Jun 18 12:06:12 creating a new children entry for `Pool' type
Jun 18 12:06:12 added `Pool' child 0x57b000 to `Global' scope 0x576400
Jun 18 12:06:12 allocated new scope `Pool' type 2 size 1224
Jun 18 12:06:12 -- looking for pool with subnet 192.168.4.0, prefix length 24
Jun 18 12:06:12 added pool `192.168.4.0/24' with subnet 192.168.4.0
Jun 18 12:06:12 set range on pool `192.168.4.0/24' to 192.168.4.1, 192.168.4.254
Jun 18 12:06:12 set range on pool `192.168.4.0/24' to 192.168.4.100, 192.168.4.200
Jun 18 12:06:12 reading lease time options for pool
Jun 18 12:06:12 Maximum lease time infinite obtained from `Global' scope
Jun 18 12:06:12 Default lease time 1 day obtained from `Global' scope
Jun 18 12:06:12 reading common options for pool
Jun 18 12:06:12 propagate settings done - number of ifls in scope 0x57b000 are 0
Jun 18 12:06:12 reading name-server
Jun 18 12:06:12 reading router
Jun 18 12:06:12 Set 1 router address on `Pool' scope
Jun 18 12:06:12 Reading static bindings
Jun 18 12:06:12 Reading interface configuration
!
perrin@srx_nz# run show system services dhcp binding 
IP address       Hardware address   Type     Lease expires at
192.168.4.101    dc:9f:db:1a:e0:35  dynamic  2014-06-19 12:06:14 UTC
192.168.4.100    dc:9f:db:1a:e0:51  dynamic  2014-06-19 12:06:13 UTC

This indeed works but by no means is it pretty, by adding filters and removing the interface from the VRF, you introduce unnecessary complexity and solutions that aren’t very scalable. Fortunately as I mentioned earlier, after 12.1 there is now a fix for this using the “access address-assignment” command inside the routing-instance hierarchy.

set access address-assignment pool guest family inet network 192.168.4.0/24
set access address-assignment pool guest family inet range pool low 192.168.4.100
set access address-assignment pool guest family inet range pool high 192.168.4.200
set access address-assignment pool guest family inet dhcp-attributes maximum-lease-time 7200
set access address-assignment pool guest family inet dhcp-attributes name-server 8.8.8.8
set access address-assignment pool guest family inet dhcp-attributes router 192.168.4.1
!
set routing-instances guest system services dhcp-local-server group guest interface vlan.30

That last line is the new feature introduced from 12.1 (I’m using 12.1X46-D20.5) It just seems too easy but this is all you need to do to assign the address assignment pool to the virtual-router. To verify this configuration, you can again check the dhcp logs, otherwise you can do it the normal way by checking the server bindings. The way you’ve always checked it using “show dhcp server binding routing-instance” or you can check it using the network-access command

perrin@srx_nz> show network-access address-assignment pool guest routing-instance guest.

Cool! DHCP in VRFs in Junos OS! Cheers to Fraser McGlinn for throwing some questions back and forth with me to come up with this.

Juniper Junos Host Zone

I recently have been building some new firewalls and finally got a chance to play with a feature released with 11.4 junos os. Using the junos-host security zone to statefully firewall incoming RE based traffic instead of using a stateless firewall filter say on the router/firewalls loopback. I am still yet to see the full advantages and disadvantages of using such a system to protect the firewall. From what I can tell, if you had lets say 5 zones you wanted to protect them from the “outside” you would have to write the same policy for every zone that you have on the system. i.e. from the internet to junos-host, from accounts to junos-host, from sales to junos-host, from engineering to junos-host; That would go on for all zones you would want to permit access to the SRX. In my example here, I only want to secure against the zone that the internet has been placed in. So its a simple and single to and from zone policy.

Here is my policy configuration from a zone ive called untrust for demonstration purposes to the junos-host zone

set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match source-address allowed_hosts
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match destination-address any
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match application junos-icmp-all
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match application junos-radius
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match application junos-snmp-agentx
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match application junos-ssh
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match application junos-bgp
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match application junos-http
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match application junos-https
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match application junos-ospf
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect match application junos-tacacs
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect then permit
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect then log session-init
set security policies from-zone untrust to-zone junos-host policy routing-engine-protect then count

set security policies from-zone untrust to-zone junos-host policy routing-engine-snmp match source-address allowed_hosts_snmp
set security policies from-zone untrust to-zone junos-host policy routing-engine-snmp match destination-address any
set security policies from-zone untrust to-zone junos-host policy routing-engine-snmp match application snmp
set security policies from-zone untrust to-zone junos-host policy routing-engine-snmp then permit
set security policies from-zone untrust to-zone junos-host policy routing-engine-snmp then log session-init
set security policies from-zone untrust to-zone junos-host policy routing-engine-snmp then count

I have created two policies here, one for general protocols and remote access and another just for SNMP. I have created some address sets for the source traffic I want to permit accessing this firewall. These are management servers and consoles that should be allowed to interact with the firewall.

Another point worth noting here is even though you are allowing various protocols in the security policy, Junos OS still requires you to add the protocols and system services under the security zone hierarchy. There is a bit of double handling here but nothing of too much concern. An example snippet of this here:

 
set security zones security-zone untrust host-inbound-traffic system-services ping
set security zones security-zone untrust host-inbound-traffic system-services snmp
set security zones security-zone untrust host-inbound-traffic protocols bgp
set security zones security-zone untrust host-inbound-traffic protocols bfd

Initially when I set this up, nothing seemed to work. I was pretty much at the point of almost not going any further when a colleague of mine at the time had discovered that junos-host policies are completely backwards compared to standard junos security policies. As you will probably know, on the SRX platform, and for that matter, any firewall structure, the default action should be deny unless otherwise permitted explicitly. However, for the junos host zone, if you don’t deny traffic explicitly, everything will be permitted no matter if you have it matched and permitted in the policy or not. This is when a great little apply-group comes in handy to globally place a deny policy in for any combination of security policies you have on the system. Credit here for this one goes to Graham Brown @mountainrescuer (JNCIP-SEC) for coming up with this apply group and kindly sharing it with me.

set groups BLANKET_DENY_ALL_POLICY security policies from-zone <*> to-zone <*> policy DENY_ALL match source-address any
set groups BLANKET_DENY_ALL_POLICY security policies from-zone <*> to-zone <*> policy DENY_ALL match destination-address any
set groups BLANKET_DENY_ALL_POLICY security policies from-zone <*> to-zone <*> policy DENY_ALL match application any
set groups BLANKET_DENY_ALL_POLICY security policies from-zone <*> to-zone <*> policy DENY_ALL then deny
set groups BLANKET_DENY_ALL_POLICY security policies from-zone <*> to-zone <*> policy DENY_ALL then log session-init
set groups BLANKET_DENY_ALL_POLICY security policies from-zone <*> to-zone <*> policy DENY_ALL then count
set security policies apply-groups BLANKET_DENY_ALL_POLICY

And here are the results! (As of 12 something, there is this awesome command you can view to show policy hit count)

perrin@fw01.nz> show security policies hit-count | match DENY_ALL 
 3       InternetCombined InternetCombined  DENY_ALL       0            
 19      InternetCombined SRX_LAN           DENY_ALL       14355        
 22      InternetCombined Tunnel_Services   DENY_ALL       73           
 24      SRX_LAN          InternetCombined  DENY_ALL       0            
 26      SRX_LAN          Tunnel_Services   DENY_ALL       0            
 28      SRX_LAN          InternetCombined_WAN DENY_ALL    0            
 30      Tunnel_Services  InternetCombined  DENY_ALL       1083         
 33      Tunnel_Services  SRX_LAN           DENY_ALL       69606        
 36      Tunnel_Services  Tunnel_Services   DENY_ALL       0            
 39      InternetCombined_WAN SRX_LAN       DENY_ALL       5            
 42      InternetCombined_WAN Tunnel_Services DENY_ALL     479          
 44      CiscoVPN         InternetCombined  DENY_ALL       0            
 46      CiscoVPN         SRX_LAN           DENY_ALL       0

That output is from the firewall ive used in other posts here to give you an example of the output, it doesn’t actually run the junos-host zone like in this blog.

I will now show you the operation of the firewall I have implemented the junos-host zone on.

perrin@lab.fwl01.syd04> show security policies hit-count  | match junos-host                    
 1       untrust          junos-host        router_protect 5995         
 2       untrust          junos-host        DENY_ALL       214

I have done a few tests with various hosts and protocols to make sure this works as expected, specifically SNMP and SSH.
Here I will remove my cacti server that polls this firewall from the address-set that is currently allowing it to communicate via SNMP

delete security zones security-zone untrust address-book address-set vocus_monitoring address 202.124.x.x/32

You can see here that once I removed this host, the server can no longer communicate with the SRX demonstrating the global deny policy is working well.
Screen Shot 2014-03-05 at 12.57.07 pm
Once that has been rolled back, all is well again.
Screen Shot 2014-03-05 at 1.00.10 pm
Here is an example with SSH, the my server external IP has been removed from the list

perrin@server:~$ ssh perrin@175.x.x.2
ssh: connect to host 175.x.x.2 port 22: Connection timed out

with SSH enabled and server external IP added back into the address-set

perrin@server:~$ ssh perrin@175.x.x.2
perrin@175.x.x.2's password: 
--- JUNOS 12.1X44-D25.5 built 2013-10-24 20:29:21 UTC
{primary:node0}
perrin@lab.fwl01.syd04>

You can also see here the hit counts have incremented after traffic has been allowed and denied

perrin@lab.fwl01.syd04> ...hit-count | match junos-host                       
 1       untrust          junos-host        router_protect 6165         
 2       untrust          junos-host        DENY_ALL       228

On my SRX220, I use a stateless filter that does roughy the same job as this statefull filter, it really comes down to your setup and application base whether its going to be best suited to you.
For example, for me to do pretty much the same job with a firewall filter, I’m using 350 lines of “set” configuration, various policy-statements and policers at this state I like the way it works and want to keep it this way. I won’t give you the set output, and all the components that make it up, its far too long!

perrin@fw01.nz> show configuration firewall | display set | count     
Count: 350 lines

And here is the hit count, which demonstrates how many filters and policers I’m actually using!

perrin@fw01.nz> show firewall filter lo0.0-i 

Filter: lo0.0-i                                                
Counters:
Name                                                Bytes              Packets
accept-ah-lo0.0-i                                       0                    0
accept-bfd-lo0.0-i                                      0                    0
accept-bgp-lo0.0-i                               45838200               801626
accept-dhcp-lo0.0-i                               1029986                 3102
accept-dns-lo0.0-i                                   3221                   21
accept-esp-lo0.0-i                                      0                    0
accept-http-lo0.0-i                               2941611                44749
accept-ike-lo0.0-i                               23924260                63582
accept-nat_t-lo0.0-i                             10178583               110789
accept-ntp-lo0.0-i                                 846108                11133
accept-ospf-lo0.0-i                             414951400              3643606
accept-rip-igmp-lo0.0-i                                 0                    0
accept-rip-udp-lo0.0-i                                  0                    0
accept-rsvp-lo0.0-i                              37662104               418416
accept-snmp-lo0.0-i                             126560749               890182
accept-ssh-lo0.0-i                                4374951                59621
discard-all-TTL_1-unknown-lo0.0-i                       0                    0
discard-icmp-lo0.0-i                               365221                 6520
discard-ip-options-lo0.0-i                            256                    8
discard-netbios-lo0.0-i                                 0                    0
discard-tcp-lo0.0-i                                260264                 5104
discard-udp-lo0.0-i                               2554056                 7831
discard-unknown-lo0.0-i                               280                    7
no-icmp-fragments-lo0.0-i                               0                    0
Policers:
Name                                                Bytes              Packets
mgmt-police-10m-accept-ssh-lo0.0-i                                           0
mgmt-police-1m-accept-dns-lo0.0-i                                            0
mgmt-police-1m-accept-ntp-lo0.0-i                                            0
mgmt-police-5m-accept-established-tcp-fetch-lo0.0-i                          0
mgmt-police-5m-accept-established-tcp-ftp-data-lo0.0-i                       0
mgmt-police-5m-accept-established-tcp-ftp-data-syn-lo0.0-i                    0
mgmt-police-5m-accept-established-tcp-ftp-lo0.0-i                            0
mgmt-police-5m-accept-established-tcp-ssh-lo0.0-i                            0
mgmt-police-5m-accept-established-tcp-telnet-lo0.0-i                         0
mgmt-police-5m-accept-established-udp-ephemeral-lo0.0-i                      0
mgmt-police-5m-accept-icmp-lo0.0-i                                           0
mgmt-police-5m-accept-snmp-lo0.0-i                                           0
mgmt-police-5m-accept-traceroute-icmp-lo0.0-i                                0
mgmt-police-5m-accept-traceroute-tcp-lo0.0-i                                 0
mgmt-police-5m-accept-traceroute-udp-lo0.0-i                                 0

Some credit here needs to go to engineers Boye Olowoyeye and Tim Hoffman, @hoffnz (both JNCIE-SP) for doing a lot of ground work on these filters before I took them, modified and added to it.

I have found I can be far more granular with the stateless filters at my current knowledge set especially coming from a ISP background and doing a lot of firewall filters and “ACLs” for customer solutions but again it really comes down to the individual and what works best for your system.

Junos Pulse Remote access VPN with LDAP authentication

Recently I was tasked with a small Juniper SRX install for a client. One of their requirements was satellite remote access for connectivity into their production network. This had to tie into their AD environment for authentication just as the Cisco ASA did that I was replacing. I am going to do a small explanation on how to set this up and the configuration necessary to get it going. Small disclaimer, I am by no means a Microsoft expert so please forgive me If I use the wrong term, or explain something strangely.

One thing I never usually credit Junos OS for is JWeb, however for really basic remote access and site to site IPSEC VPNs, the wizard driven menu cuts down a lot of time spent and actually achieves the task rather well. In this post, i will not however be explaining the Jweb process, but the set configuration that the wizard generates.

First of all, we have the ipsec policy for the VPN.

set security ipsec policy ipsec_pol_wizard_dyn_vpn proposal-set compatible

The compatible proposal set includes a set on standard predefined parameters that are negotiated from the client application to the VPN terminator.

If you are move familiar with cisco or Juniper site to site VPNs, usually you would configure a phase 2 proposal like this

set security ipsec policy srx_nz_ipsec_policy proposals esp_aes256_sha1_3600
set security ipsec proposal esp_aes256_sha1_3600 protocol esp
set security ipsec proposal esp_aes256_sha1_3600 authentication-algorithm hmac-sha1-96
set security ipsec proposal esp_aes256_sha1_3600 encryption-algorithm aes-256-cbc
set security ipsec proposal esp_aes256_sha1_3600 lifetime-seconds 3600

However we don’t need to worry about this, the wizard creates the compatible proposal in the background. In the phase 1 setup the wizard also creates a compatible proposal. Again if you are more familiar with a static setup, it would look something like this

set security ike policy srx_nz_ike_policy proposals preshare_group5_aes256_sha1
set security ike proposal preshare_group5_aes256_sha1 authentication-method pre-shared-keys
set security ike proposal preshare_group5_aes256_sha1 dh-group group5
set security ike proposal preshare_group5_aes256_sha1 authentication-algorithm sha1
set security ike proposal preshare_group5_aes256_sha1 encryption-algorithm aes-256-cbc
set security ike proposal preshare_group5_aes256_sha1 lifetime-seconds 3600

What we are using in this example however is this:

set security ike policy ike_pol_wizard_dyn_vpn mode aggressive
set security ike policy ike_pol_wizard_dyn_vpn proposal-set compatible
set security ike policy ike_pol_wizard_dyn_vpn pre-shared-key ascii-text "$9$5F9tleM8L7Uj36CuIRdVw2aGQz3tuBLx2oZj.mzFn/tuEhy8x-cSbs2aGUjikPz3p0BSlK"

set security ike gateway gw_wizard_dyn_vpn ike-policy ike_pol_wizard_dyn_vpn
set security ike gateway gw_wizard_dyn_vpn dynamic hostname firewall01
set security ike gateway gw_wizard_dyn_vpn dynamic connections-limit 50
set security ike gateway gw_wizard_dyn_vpn dynamic ike-user-type group-ike-id
set security ike gateway gw_wizard_dyn_vpn external-interface lo0.0
set security ike gateway gw_wizard_dyn_vpn xauth access-profile dyn-vpn-ldap-xauth

The key points to note from the configuration above are the external interface and the access-profile. The external interface specifies the interface that you terminate the VPN on. This will usually be your “external” IP address, or the address that is routed over the internet. The access-profile is where we define how users are authenticated on the VPN.

set access profile dyn-vpn-ldap-xauth authentication-order ldap
set access profile dyn-vpn-ldap-xauth authentication-order password
set access profile dyn-vpn-ldap-xauth client admin firewall-user password "$9$.5n90OIcSrPf9pBEeKDiHkfT"
set access profile dyn-vpn-ldap-xauth client admin2 firewall-user password "$9$m5z6pu1yrvFnCuOBEhdbw"
set access profile dyn-vpn-ldap-xauth address-assignment pool dyn-vpn-address-pool
set access profile dyn-vpn-ldap-xauth ldap-options base-distinguished-name DC=int,DC=example,DC=co,DC=nz
set access profile dyn-vpn-ldap-xauth ldap-options search search-filter sAMAccountName=
set access profile dyn-vpn-ldap-xauth ldap-options search admin-search distinguished-name CN=SRXLDAP,CN=Users,DC=int,DC=example,DC=co,DC=nz
set access profile dyn-vpn-ldap-xauth ldap-options search admin-search password "$9$WPRLxN4aZUHquOxN-V4oJGUiH.QF/AtOJGT39Cu07-d"
set access profile dyn-vpn-ldap-xauth ldap-server 192.168.100.19 port 389

This piece of configuration is what the SRX uses to query active directory for an LDAP server. Now the specify LDAP tree configuration above I’m not an expert on, by no means am I a windows person but it helps demonstrate the full picture. Some other key points here is the authentication order and the address-assignment pool.
- Auth order: specifies order of authentication that the SRX uses. First LDAP and if unavailable, then use local auth. You can see the fullback usernames and passwords specified under “client”
- address-assignment pool: specifies the network details assigned to authenticated clients. IP/DNS etc.

The address assignment pool looks like this:

set access address-assignment pool dyn-vpn-address-pool family inet network 172.16.1.0/24
set access address-assignment pool dyn-vpn-address-pool family inet xauth-attributes primary-dns 192.168.100.19/32

Now one thing I don’t quite agree with on with the junos remote access VPN with this LDAP profile is the requirement to still configure each user configured in the LDAP server on the SRX configuration.

set security dynamic-vpn access-profile dyn-vpn-ldap-xauth
set security dynamic-vpn clients wizard-dyn-group ipsec-vpn wizard_dyn_vpn
set security dynamic-vpn clients wizard-dyn-group user admin
set security dynamic-vpn clients wizard-dyn-group user jeff
set security dynamic-vpn clients wizard-dyn-group user bob

Perhaps I’m missing something here but this seems like unnecessary double handling.

Junos requires the user to specify which remote networks the connected VPN user is able to access

set security dynamic-vpn clients wizard-dyn-group remote-protected-resources 192.168.1.0/24
set security dynamic-vpn clients wizard-dyn-group remote-protected-resources 192.168.100.0/24
set security dynamic-vpn clients wizard-dyn-group remote-protected-resources 192.168.77.0/24

The last part of this setup is the policy control for the remote user to the network resources. We need to make a policy from the external zone, to the zone where the the networks are within.

set security policies from-zone external to-zone internal policy policy_in_wizard_dyn_vpn match source-address any
set security policies from-zone external to-zone internal policy policy_in_wizard_dyn_vpn match destination-address any
set security policies from-zone external to-zone internal policy policy_in_wizard_dyn_vpn match application any
set security policies from-zone external to-zone internal policy policy_in_wizard_dyn_vpn then permit tunnel ipsec-vpn wizard_dyn_vpn

I always place this policy at the very end of the “from-zone external to-zone internal” because this policy catches source any, dest any and I don’t want to catch traffic that isn’t from a remote VPN.

Screen Shot 2014-02-17 at 10.36.37 pm
Now to test:

C:\Users\Perrin>ping 192.168.1.250
Pinging 192.168.1.250 with 32 bytes of data:
Reply from 192.168.1.250: bytes=32 time=55ms TTL=62
Reply from 192.168.1.250: bytes=32 time=60ms TTL=62
Reply from 192.168.1.250: bytes=32 time=128ms TTL=62
Reply from 192.168.1.250: bytes=32 time=124ms TTL=62
Ping statistics for 192.168.1.250:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 55ms, Maximum = 128ms, Average = 91ms
C:\Users\Perrin>

Have fun

Presenting VPLS to a SRX cluster

Image

Hi there, this is more of an open question on a scenario I’m working through at the moment on a Juniper SRX 650 cluster. One particular service that is being presented to this cluster is a VPLS service which interconnects all other offices on this particular network via smaller single chassis SRXs. I am going to be plugging in 2 x 10GB interfaces to the chassis into the VPLS environment. For redundancy, one link is going off to another POP and other to a local switch. As far as the SRX is concerned this is just a reth interface with an IP address. What I want to 100% be sure that there would be any weirdities with the operation of the VPLS as far as the PE routers are concerned dealing with a clustered SRX. I want the right MAC to show up on the right port and the traffic to flow to the chassis listed as primary for that particular reth. I’ll edit this with a diagram real soon.

Thanks!

 

vpls

IPv6 via Tunnel Broker

One of the things I can’t currently do with two ISPs I connect with is native IPv6 (with a static prefix). In the meantime, I’ve sourced IPv6 tunnels as close to my physical location as possible. Currently I have this setup in New Zealand, on a Christchurch VDSL connection with a tunnel broker to Wellington. In this post I will demonstrate the configuration required to get this up and running nice and quickly on your network. This will be based on Junos OS. Because I’m working with SRX here, we need to check the status of IPv6 and enable this if it isn’t alread

perrin@srx-nz# run show security flow status 
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: drop
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
    Advanced services data-plane memory mode: Default
  Flow trace status
    Flow tracing status: off
  Flow session distribution
    Distribution mode: RR-based

It is disabled so we need to enable it then reboot the router.

perrin@srx-nz# set security forwarding-options family inet6 mode flow-based 

perrin@srx-nz# commit check 
warning: You have enabled/disabled inet6 flow.
You must reboot the system for your change to take effect.
If you have deployed a cluster, be sure to reboot all nodes.
configuration check succeeds

 

First thing you’ll need to do is sign up to a tunnel broker. I won’t name names, these are easily available with a quick google search. Basically a tunnel broker provides means to connect to the IPv6 network which currently as of day (24/1/14) has about 16482 prefixes. This is achieved in a by routing the IPv6 traffic via an IPv4 tunnel until it reaches a destination that can route natively with IPv6. This is what I have done via an IPIP tunnel with my tunnel broker as follows:

set interfaces ip-0/0/0 unit 2 description "inet6.0 - TUNNEL_SERVICE - Tunnel to xxxx xxxx"
set interfaces ip-0/0/0 unit 2 tunnel source 202.124.x.x
set interfaces ip-0/0/0 unit 2 tunnel destination 202.21.x.x
set interfaces ip-0/0/0 unit 2 family inet
set interfaces ip-0/0/0 unit 2 family inet6 mtu 1480
set interfaces ip-0/0/0 unit 2 family inet6 address 2001:4428:x:x::2/64

Cool so if your family with IPIP tunnels, you’ll know they encapsulate IP traffic with a new IP header rewritten with a new source/dest header. Reasonably simplistic and less overhead than a GRE tunnel, which is good for my DSL connections. The tunnel broker assuaged me a /64 for the tunnel and then another /64 to assign to my LAN. You can see above, you specify in the source and destination fields, your local external IPv6 address and the tunnel brokers IPv4 address.

set interfaces vlan unit 5 family inet6 address 2001:4428:200:x::x/64

Vlan 5 is the SVI I use on my LAN which is where I need to assign the IPv6 addresses. To do this, I use the route advertisement protocol.

set protocols router-advertisement interface vlan.5 prefix 2001:4428:200:8x::/64

This assigns all the compatible devices with global IPv6 addresses.

perrin@server:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:12:79:bd:d6:8b  
          inet addr:192.168.1.50  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: 2001:4428:200:812e:x:x:x:x64 Scope:Global
**output ommited**

Naturally to route traffic out of the local network we need a default route pointing to the other end of the IPIP tunnel’s v6 address

set routing-options rib inet6.0 static route ::/0 next-hop 2001:4428:200:x::1

That’s pretty much it to be honest. Simple IPv6 routing. Be sure to find a destination as close as possible to you to eliminate any potential unnecessary latency.

To verify, I would test both on the router and the host that has been assigned the addresses dynamically.

perrin@srx-nz> ping 2001:4428:200:x::1 source 2001:4428:200:x::2  
PING6(56=40+8+8 bytes) 2001:4428:200:x::2 --> 2001:4428:200:x::1
16 bytes from 2001:4428:200:x::1, icmp_seq=0 hlim=64 time=46.450 ms
16 bytes from 2001:4428:200:x::1, icmp_seq=1 hlim=64 time=43.979 ms
16 bytes from 2001:4428:200:x::1, icmp_seq=2 hlim=64 time=45.496 ms
16 bytes from 2001:4428:200:x::1, icmp_seq=3 hlim=64 time=46.494 ms
^C
--- 2001:4428:200:x::1 ping6 statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 43.979/45.605/46.494/1.020 ms

Just a note here, Chorus NZ is running very harsh DLM profile on my VDSL resulting in a 35ms last mile latency… And from the host

perrin@server:~$ ping6 google.com
PING google.com(2404:6800:4006:806::1000) 56 data bytes
64 bytes from 2404:6800:4006:806::1000: icmp_seq=1 ttl=52 time=78.2 ms
64 bytes from 2404:6800:4006:806::1000: icmp_seq=2 ttl=52 time=78.2 ms
64 bytes from 2404:6800:4006:806::1000: icmp_seq=3 ttl=52 time=78.9 ms
64 bytes from 2404:6800:4006:806::1000: icmp_seq=4 ttl=52 time=81.9 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 78.234/79.351/81.942/1.549 ms
perrin@server:~$ ping6 snap.net.nz
PING snap.net.nz(cookiemonster.snap.net.nz) 56 data bytes
64 bytes from cookiemonster.snap.net.nz: icmp_seq=1 ttl=59 time=47.7 ms
64 bytes from cookiemonster.snap.net.nz: icmp_seq=2 ttl=59 time=47.1 ms
64 bytes from cookiemonster.snap.net.nz: icmp_seq=3 ttl=59 time=47.8 ms
64 bytes from cookiemonster.snap.net.nz: icmp_seq=4 ttl=59 time=47.9 ms
64 bytes from cookiemonster.snap.net.nz: icmp_seq=5 ttl=59 time=49.4 ms
^C
--- snap.net.nz ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 47.150/48.014/49.429/0.771 ms

That’s it. Enjoy but remember, you’ve now opened up your router to the ipv6 internet so you should make sure you secure your RE in the same way you would with IPv4 traffic for things like SSH, SNMP and any protocols you may run on the internet

MP-BGP signalled VPLS and L3 VRFs over MPLS on SRX

My last post was how to setup an RSVP based MPLS tunnel between two SRXs. These general concepts can be applied to any Juniper router like SRX, J and MX, no matter whether it’s in flow mode like my SRXs or not. In this post, I will setup a L2 VPLS and a L3 VRF and do all the verification to show you the correct operation of these running on the network. (This post will just be L2 VPLS, in the next one ill move into point to point L2 tunnels, using LDP and BGP signalling)

Currently I have a simple MPLS network using RSVP between two SRX Juniper router/firewalls. There is one path in each direction and no complicated knobs or features being utilised at this stage. What I want to be able to achieve in this post is building a Layer 3 VRF to exchange routes in and a VPLS to bridge a LAN between the two routers.

perrin@srx-au> show configuration protocols bgp | display set 
perrin@srx-au> show configuration protocols bgp group mpls-core | display set
set protocols bgp group mpls-core type internal
set protocols bgp group mpls-core multihop
set protocols bgp group mpls-core local-address 119.69.0.5
set protocols bgp group mpls-core family inet unicast
set protocols bgp group mpls-core family inet multicast
set protocols bgp group mpls-core family inet-vpn unicast
set protocols bgp group mpls-core family inet6 unicast
set protocols bgp group mpls-core family inet6 multicast
set protocols bgp group mpls-core family inet6-vpn unicast
set protocols bgp group mpls-core family l2vpn signaling
set protocols bgp group mpls-core graceful-restart
set protocols bgp group mpls-core neighbour 119.69.0.1

Just to quickly recap, here is the BGP configuration we will be using to signal our VRFs, applicable to this situation is “l2vpn signalling” and “inet-vpn unicast” These enable BGP to carry correct NLRI per service we are enabling.

I’ll start with the L3 VRF

perrin@srx-au> show configuration routing-instances |display set 
set routing-instances CORE_L3VPN_LAB instance-type vrf
set routing-instances CORE_L3VPN_LAB interface lt-0/0/0.1
set routing-instances CORE_L3VPN_LAB route-distinguisher 119.69.0.5:1001
set routing-instances CORE_L3VPN_LAB vrf-target target:64514:1001

Not too bad yeah! I'll explain a few things quickly. So firstly there is the vrf-target. This is specifying the BGP community to match when exchanging routes with other PE routers, or in this case, the SRX on the other end. This is carried across the MPLS tunnel as a secondary tag, going through a larger MPLS network this would have the top MPLS label added on top the the P routers would use to pass the traffic through to the correct egress router. VRFs will export all VRFs tagged with "64514:1001" and import them into any router with a matching target. The "route-distinguisher" essentially "distinguishes" which IP address belongs to what VRF. The RD field is added to a route when transported across the network. Naturally there is a lot more detail in what each of these two components too, but I'm trying to make this a more hands on, "lets actually configure it" exercise.

To demonstrate the redistribution of routes across this VPN, I have done a simple route import from my inet.0 table on one SRX,

set routing-options interface-routes rib-group inet inet.0-to-CORE_L3VPN_LAB
set routing-options rib-groups inet.0-to-CORE_L3VPN_LAB import-rib inet.0
set routing-options rib-groups inet.0-to-CORE_L3VPN_LAB import-rib CORE_L3VPN_LAB.inet.0

That is a rib copy to do interface routes only coping from inet.0 to CORE_L3VPN_LAB. Example before the RIB copy

perrin@srx-nz# run show route table CORE_L3VPN_LAB terse 

CORE_L3VPN_LAB.inet.0: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop         AS path
* 1.1.1.0/24         D   0                       >lt-0/0/0.1   
                     B 170        100            >gr-0/0/0.2       I
* 1.1.1.2/32         L   0                        Local
* 192.168.1.0/24     B 170        100            >gr-0/0/0.2       I

and after the RIB copy is applied

perrin@srx-nz> show route table CORE_L3VPN_LAB terse   

CORE_L3VPN_LAB.inet.0: 34 destinations, 37 routes (33 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop         AS path
* 1.1.1.0/24         D   0                       >lt-0/0/0.1   
                     B 170        100            >gr-0/0/0.2       I
* 1.1.1.2/32         L   0                        Local
* 10.0.2.0/24        D   0                       >lo0.0        
* 10.0.2.1/32        L   0                        Local
* 10.0.252.0/31      D   0                       >gr-0/0/0.3   
* 10.0.252.0/32      L   0                        Local
* 10.0.255.0/31      D   0                       >gr-0/0/0.0   
* 10.0.255.0/32      L   0                        Local
* 10.0.255.2/31      D   0                       >ip-0/0/0.3   
* 10.0.255.2/32      L   0                        Local
* 10.0.255.4/31      D   0                       >gr-0/0/0.2   
* 10.0.255.4/32      L   0                        Local
* 10.0.255.12/30     D   0                       >gr-0/0/0.0   
* 10.0.255.13/32     L   0                        Local
* 10.0.255.240/30    D   0                       >ip-0/0/0.0   
* 10.0.255.242/32    L   0                        Local
* 119.69.0.1/32      D   0                       >lo0.0        
* 172.16.1.0/30      D   0                       >vlan.20      
* 172.16.1.1/32      L   0                        Local
* 172.16.2.0/32      D   0                       >lo0.0        
* 172.16.5.0/31      D   0                       >vlan.30      
* 172.16.5.0/32      L   0                        Local
* 172.16.31.254/32   D   0                       >lo0.0        
* 172.31.255.254/32  D   0                       >lo0.0        
* 172.32.255.254/32  D   0                       >lo0.0        
* 192.168.0.16/30    D   0                       >gr-0/0/0.1   
* 192.168.0.18/32    L   0                        Local
* 192.168.1.0/24     D   0                       >vlan.5       
                     B 170        100            >gr-0/0/0.2       I
* 192.168.1.2/32     L   0                        Local
* 192.168.1.251/32   L   0                        Local
* 202.124.101.64/29  D   0                       >ge-0/0/0.0   
                     D   0                       >ge-0/0/0.0   
* 202.124.101.66/32  L   0                        Local
* 202.124.101.69/32  L   0                        Local

As you can see here we have a heap of routes now populated that are traditionally interface routes on the srx_nz router. All going to plan, the routes should have now been transported via the MPLS tunnel to the other end.

perrin@srx-au> show route table CORE_L3VPN_LAB.inet.0          

CORE_L3VPN_LAB.inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.0/24         *[Direct/0] 6d 03:57:59
                    > via lt-0/0/0.1
1.1.1.1/32         *[Local/0] 6d 03:57:59
                      Local via lt-0/0/0.1
10.0.2.0/24        *[BGP/170] 00:01:10, localpref 100, from 119.69.0.1
                      AS path: I
                    > via gr-0/0/0.2, label-switched-path 5-to-1
10.0.2.1/32        *[BGP/170] 00:01:10, localpref 100, from 119.69.0.1
                      AS path: I
                    > via gr-0/0/0.2, label-switched-path 5-to-1
10.0.252.0/31      *[BGP/170] 00:01:10, localpref 100, from 119.69.0.1
                      AS path: I
                    > via gr-0/0/0.2, label-switched-path 5-to-1
10.0.255.0/31      *[BGP/170] 00:01:10, localpref 100, from 119.69.0.1
                      AS path: I
                    > via gr-0/0/0.2, label-switched-path 5-to-1
10.0.255.2/31      *[BGP/170] 00:01:10, localpref 100, from 119.69.0.1
***output ommited***

Excellent, everything is working well, I haven't displayed everything here but you get the idea. All the routes have been learned from BGP via LSP 5-to-1, if you were using a route reflector for your BGP, then that would be where the "from 119.69.0.1" for my lab just have the BGP point to point. By default, BGP is the only routing protocol that can view the inet.3 table which it uses to resolve the next hop.

perrin@srx-au> show route table inet.3    
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

119.69.0.1/32      *[RSVP/7/1] 05:01:26, metric 1
                    > via gr-0/0/0.2, label-switched-path 5-to-1

For a more in-depth look at routes, you can add the extensive flag on the end to view more detailed information like BGP attributes and label information

perrin@srx-au> show route table CORE_L3VPN_LAB.inet.0 10.0.2.0/24 extensive 

CORE_L3VPN_LAB.inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
10.0.2.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.0.2.0/24 -> {indirect(262146)}
        *BGP    Preference: 170/-101
                Route Distinguisher: 119.69.0.1:1001
                Next hop type: Indirect
                Address: 0x15b95bc
                Next-hop reference count: 18
                Source: 119.69.0.1
                Next hop type: Router, Next hop index: 643
                Next hop: via gr-0/0/0.2 weight 0x1, selected
                Label-switched-path 5-to-1
                Label operation: Push 315504
                Label TTL action: prop-ttl
                Protocol next hop: 119.69.0.1
                Push 315504
                Indirect next hop: 1694bc8 262146
                State: 
                Local AS: 64514 Peer AS: 64514
                Age: 53:00 	Metric2: 1 
                Task: BGP_64514.119.69.0.1+179
                Announcement bits (1): 1-KRT 
                AS path: I
                Communities: target:64514:1001
                Import Accepted
                VPN Label: 315504
                Localpref: 100
                Router ID: 119.69.0.1
                Primary Routing Table bgp.l3vpn.0
                Indirect next hops: 1
                        Protocol next hop: 119.69.0.1 Metric: 1
                        Push 315504
                        Indirect next hop: 1694bc8 262146
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: via gr-0/0/0.2 weight 0x1
			119.69.0.1/32 Originating RIB: inet.3
			  Metric: 1			  Node path count: 1
			  Forwarding nexthops: 1
				Nexthop: via gr-0/0/0.2

Thats pretty much that sorted. A fully operational L3 VRF using RSVP MPLS. Now I'll show you the VPLS.

perrin@srx-au> show configuration routing-instances CORE_VPLS_LAB | display set 
set routing-instances CORE_VPLS_LAB instance-type vpls
set routing-instances CORE_VPLS_LAB vlan-id none
set routing-instances CORE_VPLS_LAB interface lt-0/0/0.0
set routing-instances CORE_VPLS_LAB route-distinguisher 119.69.0.5:1000
set routing-instances CORE_VPLS_LAB vrf-target target:64514:1000
set routing-instances CORE_VPLS_LAB protocols vpls site-range 255
set routing-instances CORE_VPLS_LAB protocols vpls no-tunnel-services
set routing-instances CORE_VPLS_LAB protocols vpls site srx-au site-identifier 5
set routing-instances CORE_VPLS_LAB protocols vpls connectivity-type ce

This is example assumes prior knowledge of VPLS operation, thinks like mac address transporting and components with NLRI for VPLS attributes. With the VPLS configured on both sides, we can verify it with these few commands. Also things like vrf-target and route-distinguisher share very similar properties here in application as they do with L3 VRFs

perrin@srx-au> show vpls connections 
**output ommited**
Instance: CORE_VPLS_LAB
  Local site: srx-au (5)
    connection-site           Type  St     Time last up          # Up trans
    1                         rmt   Up     Jan 20 17:00:59 2014           1
      Remote PE: 119.69.0.1, Negotiated control-word: No
      Incoming label: 262145, Outgoing label: 262157
      Local interface: lsi.1051648, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls CORE_VPLS_LAB local site 5 remote site 1
perrin@srx-au> show route table CORE_VPLS_LAB 

CORE_VPLS_LAB.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

119.69.0.1:1000:1:1/96                
                   *[BGP/170] 05:29:56, localpref 100, from 119.69.0.1
                      AS path: I
                    > via gr-0/0/0.2, label-switched-path 5-to-1
119.69.0.5:1000:5:1/96                
                   *[L2VPN/170/-101] 6d 04:38:11, metric2 1
                      Indirect

Here you can see the remote VPLS site is signed as UP, that command also shows some label operation and the local label switched interface. LSI's are used when no-tunnel-services as you longer need to use a tunnel pic to run VPLS.

We can go into more detail my adding the extensive command on the end to view things like community tags and local-pref

perrin@srx-au> show route table CORE_VPLS_LAB extensive 

CORE_VPLS_LAB.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
 119.69.0.1:1000:1:1/96 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 119.69.0.1:1000
                Next hop type: Indirect
                Address: 0x15ba0b8
                Next-hop reference count: 5
                Source: 119.69.0.1
                Protocol next hop: 119.69.0.1
                Indirect next hop: 2 no-forward
                State: 
                Local AS: 64514 Peer AS: 64514
                Age: 5:38:48 	Metric2: 1 
                Task: BGP_64514.119.69.0.1+179
                Announcement bits (1): 0-CORE_VPLS_LAB-l2vpn 
                AS path: I
                Communities: target:64514:1000 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
                Import Accepted
                Label-base: 262153, range: 8
                Localpref: 100
                Router ID: 119.69.0.1
                Primary Routing Table bgp.l2vpn.0
                Indirect next hops: 1
                        Protocol next hop: 119.69.0.1 Metric: 1
                        Indirect next hop: 2 no-forward
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: via gr-0/0/0.2 weight 0x1
			119.69.0.1/32 Originating RIB: inet.3
			  Metric: 1			  Node path count: 1
			  Forwarding nexthops: 1
				Nexthop: via gr-0/0/0.2
**output ommited**

Unfortunately one really crucial command in my opinion that seems to be missing from the SRX platform is the "show vpls mac-table" command. This can be used to view the bridging table of the VPLS instance. Remote sites show up as their appropriate LSI interfaces with the 48 bit mac address and locally learnt macs via the local interface. i.e. ge-0/0/0 or in my case lt-0/0/0.0 Of course on a proper MPLS router like the MX line, these commands are all supported and work well.

That raps up a quick overview on how to provision simple VPLS and L3 services over MP-BGP signalled MPLS. I can appreciate that this kind of configuration is all over the internet but here I am trying to demonstrate a working model over some very basic juniper routers, at low cost and between two countries :) Enjoy and stay tuned for some reading on LDP based technology and more advanced RSVP-TE concepts.

RSVP based MPLS over GRE on a Flow based Juniper SRX

Recently I moved from Christchurch to Sydney and wanted to have some fun doing various labs and tests between two SRXs, one over here and the other in Christchurch. These were mentioned in my first blog if you haven’t already seen. The reason I’m writing this blog is I’ve found a gap online where I can’t seem to find anyone who has written up something for doing RSVP based MPLSoGRE. There are a few variants, some using LDPoGRE or LDPoGREoIPSEC which is all very good, but if you’re like me, you’ll love the power and granuality of RSVP. The other reason is my move also took me into a new company that doesn’t use Juniper mainstream on the SP network, and any Junos OS I could use to do anything was keeping me sane!

Aside from doing virtual labs on VMWare firefly machines, I wanted to give this real world scenario a go, that being, running an MPLS network between Christchurch and Sydney on two simple DSL connections using SRX. Currently and as far to my knowledge, SRXs can’t do MPLS in flow mode, however, Junos OS allows you to manually change traffic to packet mode which ill demonstrate soon. OF course you could have your SRX or J series router in packet mode, but depending on the application of your Juniper device, that may just not suit. Firstly I’ll verify for you that my SRX is in flow mode

<perrin@srx-au> show security flow status 
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: drop
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
    Advanced services data-plane memory mode: Default
  Flow trace status
    Flow tracing status: off
  Flow session distribution
    Distribution mode: RR-based>

Setting up the configuration

This example will use GRE between two public IP addresses and won’t run over a IPSEC VPN. (If you wanted to you would just setup the GRE tunnel with the two addresses specified inside the IPSEC section of your VPN)

set security ipsec vpn srx_aus ike proxy-identity local 172.32.255.254/32
set security ipsec vpn srx_aus ike proxy-identity remote 172.32.255.255/32

I’ll make another post on more detail for this kind of setup. Anyhow, standard GRE..

set interfaces gr-0/0/0 unit 2 description "inet.0 - TUNNEL_SERVICE - Australia SRX GRE Tunnel for MPLS"
set interfaces gr-0/0/0 unit 2 tunnel source 20.20.20.20 
set interfaces gr-0/0/0 unit 2 tunnel destination 30.30.30.30
set interfaces gr-0/0/0 unit 2 family inet mtu 1516
set interfaces gr-0/0/0 unit 2 family inet address 10.0.255.4/31
set interfaces gr-0/0/0 unit 2 family mpls filter input MPLS-packet-mode

and loopback:

set interfaces lo0 unit 0 family inet address 119.69.0.5/32

I’ll quickly confirm the GRE tunnel operation.

perrin@srx-au> ping 10.0.255.4 source 10.0.255.5 count 5 
PING 10.0.255.4 (10.0.255.4): 56 data bytes
64 bytes from 10.0.255.4: icmp_seq=0 ttl=64 time=75.513 ms
64 bytes from 10.0.255.4: icmp_seq=1 ttl=64 time=74.488 ms
64 bytes from 10.0.255.4: icmp_seq=2 ttl=64 time=74.344 ms
64 bytes from 10.0.255.4: icmp_seq=3 ttl=64 time=73.671 ms
64 bytes from 10.0.255.4: icmp_seq=4 ttl=64 time=74.476 ms

--- 10.0.255.4 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 73.671/74.498/75.513/0.590 ms

You’ll notice I have a firewall filter added to family MPLS on the GRE interface. This is the key to running the MPLS on a flow based SRX.

perrin@srx-nz> show configuration firewall family mpls filter MPLS-packet-mode | display set    
set firewall family mpls filter MPLS-packet-mode term all-traffic then packet-mode
set firewall family mpls filter MPLS-packet-mode term all-traffic then accept

As this filter has no “from” statement, all traffic is matched then processed with “then” and as you can see I’m turning packet-mode on for MPLS traffic only”
Because the rest my SRX environment is still running in flow mode, there are a few small things that need to be accounted for. One of those is “intra-zone” traffic, that is, two interfaces inside the same zone, talking to each other. In this particular setup, that is communication between lo0 and gr-0/0/0.2. To keep things simple for this example, I have added a allow all policy for this zone.

set security policies from-zone Tunnel_Services to-zone Tunnel_Services policy allow_all match source-address any
set security policies from-zone Tunnel_Services to-zone Tunnel_Services policy allow_all match destination-address any
set security policies from-zone Tunnel_Services to-zone Tunnel_Services policy allow_all match application any
set security policies from-zone Tunnel_Services to-zone Tunnel_Services policy allow_all then permit

Here you can see that loopback traffic transit gr-0/0/0.2

Session ID: 11663, Policy name: allow_all/9, Timeout: 1772, Valid
  In: 119.69.0.1/1 --> 119.69.0.5/1;rsvp, If: gr-0/0/0.2, Pkts: 1671, Bytes: 373840
  Out: 119.69.0.5/1 --> 119.69.0.1/1;rsvp, If: .local..0, Pkts: 0, Bytes: 0

Security Zone config for interfaces participating in the MPLS

perrin@srx-au> show configuration security zones security-zone Tunnel_Services | display set
set security zones security-zone Tunnel_Services interfaces gr-0/0/0.2 host-inbound-traffic protocols all
set security zones security-zone Tunnel_Services interfaces lo0.0 host-inbound-traffic protocols all

Now for the basic MPLS and RSVP configuration:

perrin@srx-au> show configuration protocols mpls | display set 
set protocols mpls label-switched-path 5-to-1 to 119.69.0.1
set protocols mpls interface gr-0/0/0.2
perrin@srx-au> show configuration protocols rsvp | display set    
set protocols rsvp interface gr-0/0/0.2

It’s a very simple configuration set and I’m only specifying one very basic LSP, at this stage I am not running, primary/seconday paths with fast reroute etc. Just keeping it basic for this demonstration. (there will be further blogs with more advanced CSPF material) The backbone of any MPLS network in a service provider network, is a solid IGP configuration and in my case MP-BGP with all the right knobs turned on for the type of traffic I want to run over this network. Here is my example OSPF and BGP configuration.

perrin@srx-au> show configuration protocols ospf | display set 
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface gr-0/0/0.2 interface-type p2p

perrin@srx-au> show configuration protocols bgp group mpls-core | display set
set protocols bgp group mpls-core type internal
set protocols bgp group mpls-core multihop
set protocols bgp group mpls-core local-address 119.69.0.5
set protocols bgp group mpls-core family inet unicast
set protocols bgp group mpls-core family inet multicast
set protocols bgp group mpls-core family inet-vpn unicast
set protocols bgp group mpls-core family inet6 unicast
set protocols bgp group mpls-core family inet6 multicast
set protocols bgp group mpls-core family inet6-vpn unicast
set protocols bgp group mpls-core family l2vpn signaling
set protocols bgp group mpls-core graceful-restart
set protocols bgp group mpls-core neighbour 119.69.0.1

OSPF here is pretty straight forward. I have changed the interface type to point to point mode. Usually OSPF listens on multicast address 224.0.0.5, but instead now the SRX will unicast the OSPF packets to the remote instead of mulicast. Makes sense when there is only one device listening. You need to make 100% sure you have traffic engineering turned on else your LSPs won’t stand up. OSPF uses Type 10 opaque LSAs to carry traffic engineering extensions. This populates the traffic engineering database with this information. As you can see above there is a few more BGP parameters setup, many of these needed for our setup here. For example, to enable your bgp to carry network layer reachability information (NLRI) for particular traffic types, I’ve setup the “inet unicast” likewise with “inet6″ for ipv6 information. What we are going to use here most of all is “l2vpn signalling” and “inet-vpn unicast” for VPLS and L3 VRFs.

Verification

Lets do some verification for what we have done so far. OSPF and BGP are standing up

perrin@srx-au> show ospf neighbor 
Address          Interface              State     ID               Pri  Dead
10.0.255.4       gr-0/0/0.2             Full      111.69.0.1       128    32

perrin@srx-au> show ospf database opaque-area 

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
OpaqArea 1.0.0.1          111.69.0.1       0x8000001e  1076  0x22 0x178f  28
OpaqArea*1.0.0.1          111.69.0.5       0x8000001e  1479  0x22 0x2777  28
OpaqArea 1.0.0.3          111.69.0.1       0x8000002c   120  0x22 0xded0 136
OpaqArea*1.0.0.3          111.69.0.5       0x8000002c   119  0x22 0x7d39 136

perrin@srx-au> show bgp neighbor 119.69.0.1     
Peer: 119.69.0.1+56907 AS 64514 Local: 119.69.0.5+179 AS 64514
  Type: Internal    State: Established    Flags: 
**Output ommited**

Great everything is working so far. One thing I would recommend checking is that your OSPF database contains OpaqArea LSA types! If you add a detail on the end of that command you will get a world of information about what TE stuff OSPF is transporting. When the BGP neighbour is being checked, you can verify all the address families that have been configured

perrin@srx-au> show bgp neighbor 111.69.0.1 | match "Address families" 
  Address families configured: inet-unicast inet-multicast inet-vpn-unicast inet6-unicast inet6-multicast inet6-vpn-unicast l2vpn-signaling

Right lets check the MPLS side of things starting with whether the LSP is up.

perrin@srx-au> show rsvp interface 
RSVP interface: 1 active
                  Active Subscr- Static      Available   Reserved    Highwater
Interface   State resv   iption  BW          BW          BW          mark
gr-0/0/0.2  Up         1   100%  800Mbps     800Mbps     0bps        0bps  

perrin@srx-au> show mpls lsp 
Ingress LSP: 2 sessions
To              From            State Rt P     ActivePath       LSPname
119.69.0.1      191.69.0.5      Up     0 *                      5-to-1
Total 2 displayed, Up 1, Down 1

Egress LSP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
119.69.0.5      119.69.0.1      Up       0  1 FF       3        - 1-to-5
Total 1 displayed, Up 1, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

We can also verify the CSPF operation by adding detail on the end of the previous command.

perrin@srx-au> show mpls lsp detail ingress 
Ingress LSP: 2 sessions

111.69.0.1
  From: 111.69.0.5, State: Up, ActiveRoute: 0, LSPname: 5-to-1
  ActivePath:  (primary)
  LSPtype: Static Configured
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                    State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 1)
 10.0.255.4 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.0.255.4

You can see here that the LSP has successfully negioated a ERO (Explicit Route Object) and received a confirmation RRO (Route Record Object). To quickly summarise what these are, the ERO will list either loose or strict LSRs the LSP must transit. The RRO is a record of LSRs the LSP has transited to establish the path, essentially a list of address the path has gone through.
Now remember, when creating an LSP, you are building a path in one direction, this is not an automatic bidirectional path so you must remember to create a mirrored path on your remote device. This can be verified with “show mpls lsp” command and confirming you have a ingress and egress LSP. Naturally if you were running and LDP based MPLS topology things would be a little difference, but for RSVP, thats how we take care of business.
At this stage, you are pretty much ready to add your L2 and L3 VRFs into the mix and get some traffic running across this link. I will make another post on configuring these and I will go into further detail on setup and verification.

I hope this will serve as a real world working example that will help with studies or maybe even a production application for anyone who is interested. From here, I will be adding some posts on some more advanced features of RSVP like using fast reroute, primary, secondary paths and some other cool stuff like that in the future as well!

Source NAT off for SSH access to Junos OS security device

Quick tip if you run an SRX/J series router in an office or home environment and you are connecting to the devices external IP address for SSH access from within the internal LAN. Ok so you have some really simple NAT rules for your trusted network’s source NAT. ie.

set security nat source rule-set SRX_LAN-to-InternetCombined from zone SRX_LAN
set security nat source rule-set SRX_LAN-to-InternetCombined to zone InternetCombined
set security nat source rule-set SRX_LAN-to-InternetCombined rule Interface_NAT_1 match source-address 192.168.5.0/24
set security nat source rule-set SRX_LAN-to-InternetCombined rule Interface_NAT_1 match destination-address 0.0.0.0/0
set security nat source rule-set SRX_LAN-to-InternetCombined rule Interface_NAT_1 then source-nat interface

The issue I’ve come across with this setup, is when creating an SSH session from 192.168.5.x to the routers external IP address, my very generic and broad destination address rule catches this and turns on source NAT, essentially making my session look like (my external IP for this example is 1.1.1.1) 1.1.1.1 is trying to SSH to 1.1.1.1. This just gets all kinds of annoying and I don’t want to have to create policies or complicated flow based ways around this and also 1.1.1.1 isn’t inside my SRX_LAN zone if your following the from and to NAT statements. SO easiest way is a little bit of source nat off, which disables the NAT function, per term or rule that you specify. This makes my config look like this instead.

set security nat source rule-set SRX_LAN-to-InternetCombined from zone SRX_LAN
set security nat source rule-set SRX_LAN-to-InternetCombined to zone InternetCombined
set security nat source rule-set SRX_LAN-to-InternetCombined rule Interface_NAT_0 match source-address 192.168.5.0/24
set security nat source rule-set SRX_LAN-to-InternetCombined rule Interface_NAT_0 match destination-address 1.1.1.1/32
set security nat source rule-set SRX_LAN-to-InternetCombined rule Interface_NAT_0 match destination-port 22
set security nat source rule-set SRX_LAN-to-InternetCombined rule Interface_NAT_0 then source-nat off
set security nat source rule-set SRX_LAN-to-InternetCombined rule Interface_NAT_1 match source-address 192.168.5.0/24
set security nat source rule-set SRX_LAN-to-InternetCombined rule Interface_NAT_1 match destination-address 0.0.0.0/0
set security nat source rule-set SRX_LAN-to-InternetCombined rule Interface_NAT_1 then source-nat interface

Ive created a small rule inserted before rule Interface_NAT_1 that matches the LAN source of 192.168.5.0/24, dest port of 22 and turns source NAT off. Simple and easy for a home user. What actually got me doing this was I use a connection manager for devices I need to manage, this list would be upwards of more than 100 devices so I didn’t want to have duplicates of the same device just to access the internal or external interface depending on where I was located at the time. Having just the one with the external IP address is now all i need.

SRX and IRB interface compatibility

So I was doing so labbing on the gear I have physically at the moment and came across some unusual and potentially buggy piece of config on a Juniper SRX 110H and a 220H. I’ll set the scene really quickly. I have an SRX 110 and 220 one in Christchurch, New Zealand and the other in Sydney. Between them I am running a RSVP MLSP connection over GRE. These are running in full flow firewall mode with exceptions for MPLS etc.

So aim of the lab was to setup a VPLS between the two sites and to test its operation. Fairly standard set of work for those familiar, however as you may know, it is hard to test end to end connectivity via basic tools such as ping or trace route unless you have devices on the end of interfaces that have been adding into the VPN especially setup and all that. I just wanted a proof of concept and usually when I’m testing a VPLS end to end, I use a routing interface within a VPLS  in the form of an IRB interface, which in turn is added into a L3 VRF. The idea being pinging via the L3 VRF, across the VPLS, and back into the remote side L3 VRF. Easy right? Well the SRX did not like the IRB interface, and I’m not talking about unsupported platforms, software or anything like that.

First off lets get some config:

set routing-instances CORE_VPLS_LAB instance-type vpls
set routing-instances CORE_VPLS_LAB vlan-id none
set routing-instances CORE_VPLS_LAB routing-interface irb.10
set routing-instances CORE_VPLS_LAB route-distinguisher 192.168.1.1:1000
set routing-instances CORE_VPLS_LAB vrf-target target:64514:1000
set routing-instances CORE_VPLS_LAB protocols vpls site-range 255
set routing-instances CORE_VPLS_LAB protocols vpls no-tunnel-services
set routing-instances CORE_VPLS_LAB protocols vpls site srx-au site-identifier 1
set routing-instances CORE_VPLS_LAB protocols vpls connectivity-type irb

..and the L3 VRF side

set routing-instances CORE_L3VPN_LAB instance-type vrf
set routing-instances CORE_L3VPN_LAB interface irb.10
set routing-instances CORE_L3VPN_LAB route-distinguisher 192.168.1.11001
set routing-instances CORE_L3VPN_LAB vrf-target target:64514:1001

.. and the irb interface

set interfaces irb unit 10 family inet address 1.1.1.1/24

Ok, so the interface has been added into the correct VRF/VPN, however on this SRX, the issue I came across was the system DOES NOT recognise that the interface has been added into a VRF/VPN and therefore stays in a DOWN state.
Shown here..

perrin@srx-au# run show interfaces terse irb                 
Interface               Admin Link Proto    Local                 Remote
irb                     up    up  
irb.10                  up    down inet     1.1.1.1/24

.. and here lies the problem

perrin@srx-au# run show interfaces irb.10    
  Logical interface irb.10 (Index 92) (SNMP ifIndex 591) 
    Flags: Hardware-Down SNMP-Traps 0x0 Encapsulation: ENET2
    Bandwidth: 1000mbps
    Routing Instance: None Bridging Domain: None
    Input packets : 0 
    Output packets: 0
    Security: Zone: Null
    Protocol inet, MTU: 1514
      Flags: Sendbcast-pkt-to-re
      Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
        Destination: 1.1.1/24, Local: 1.1.1.1, Broadcast: 1.1.1.255

Essentially I am stuck here, even with a JNCIE-SP glancing over it briefly we couldn’t come up with a instant fix for my testing procedures using an IRB interface. It is certainly an interesting one and the SRX naturally can’t ping the IRB locally either. Now disclaimer, SRXs are the jack of all trades, master of none, at least thats my opinion of the low end branch series devices, so it therefore could something I’m missing that is platform specific that isn’t showing up in the usual places, or (help me) I’ve configured something wrong. Either way I thought it was certainly of interest especially to anyone dealing with L2/L3 troubleshooting and deployment. These devices are both running JUNOS Software Release [12.1X44-D25.5]