Tag: juniper

Configuring a VPN tunnel from a VRF

Nils Magnus Eliassen1 Comment

In the company where I work we deliver some of our product using boats. Since most of our customers are in remote locations we use a supplier that have good coverage in those locations. The issue then becomes that the same supplier has a high cost on the bandwidth and they don’t have a good coverage in the areas where our factories are. To reduce cost and ensure good coverage close to our factories we have a wireless network that the boats connect to when they arrive. I have added a picture with a simple diagram showing the solution.
Boat network

At the moment we have Juniper SSG550M in a central location as our VPN hub. We have just recently started to buy Cisco routers instead of Juniper firewalls for the boats. So I had to configure the Cisco routers so they would automatically switch between the 2 connections and always try to choose our wireless connection first (the connection close to our factories).

I did this with the help of BGP and gave the expensive connection more AS path compared to our wireless connection at the factories. The VPN is a VTI/Routing based tunnel.

I will first start with the configuration of the Cisco router. In the first section here I am configuring the settings of the VPN tunnel:

crypto isakmp policy 10
encr aes 256
authentication pre-share
group 14
lifetime 3600
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10
!
crypto ipsec transform-set aes256-sha esp-aes 256 esp-sha-hmac
mode tunnel
!
!
crypto ipsec profile boat-vpn
set transform-set aes256-sha
set pfs group14

With all the options set I can build the tunnel itself. The first tunnel is the one wireless in the factories. I have put the connection into a separate vrf to avoid conflicts between the two connections. I also want all the internet traffic to go over the “expensive connection”. Since the boats visit different factories I only have a dynamic IP at the boats. Every time they arrive at a factory they will receive a new IP, so the tunnel is configured with aggressive mode and identified by the fqdn name. Also remember to use another password than supersecret 🙂

ip vrf factorywireless
crypto isakmp peer address 192.168.2.1 vrf factorywireless
set aggressive-mode password supersecret
set aggressive-mode client-endpoint fqdn boat.example.com

For the second and primary connection I will use the default router instance. This is the connection that will have coverage most of the time and is where the internet traffic will be running . This connection is also using aggressive mode.

crypto isakmp peer address 8.8.8.8
set aggressive-mode password supersecret
set aggressive-mode client-endpoint fqdn boat-dialup.example.com

The interfaces for the tunnel are configured pretty straight forward as a normal VTI interfaces. The only difference is that the tunnel that connects from the factorywireless vrf has a line about that.

interface Tunnel1
description Tunnel over ICE
ip address 10.0.1.6 255.255.255.252
tunnel source FastEthernet4
tunnel mode ipsec ipv4
tunnel destination 8.8.8.8
tunnel protection ipsec profile boat-vpn
!
interface Tunnel105
description Tunnel over Wireless at factories
ip address 10.0.1.2 255.255.255.252
tunnel source Vlan110
tunnel mode ipsec ipv4
tunnel vrf factorywireless
tunnel destination 192.168.2.1
tunnel protection ipsec profile boat-vpn

The last thing we need to do on the Cisco router is to configure the BGP. This is to make sure the traffic is routed on the correct path. You can see that I have added route map prepend-internet  where I have configured 4 extra prepends to the AS path. I only configure the AS path on an outgoing basis so you will see the same amount of prepends on the Netscreen. The prepend is only configured on the traffic going over the expensive internet connection.

router bgp 64501
bgp log-neighbor-changes
network 10.2.1.0 mask 255.255.255.192
neighbor 10.0.111.1 remote-as 64590
neighbor 10.0.111.1 route-map prepend-internet out
neighbor 10.0.111.5 remote-as 64500
!
route-map prepend-internet permit 10
 set as-path prepend 64501 64501 64501 64501

 

 

That completes the configuration of the Cisco router. We will now start on the configuration on the SSG550M. I will start with the configuration of the VPN proposal. It’s important that these match the Cisco device that we tested with before.

 set ike p1-proposal "vpn-boats-phase1" preshare group14 esp aes256 sha-1 second 3600
 set ike p2-proposal vpn-boats-phase-2 group14 esp aes256 sha-1 second 3600

Then we will create the connection for the VPN tunnels. We will start on the factory wireless connection. Since we never know what IP address the tunnel is coming from this will be an aggressive tunnel. Remember to type the fqdn name for the connection correct in the first line and choose the correct interface. The interface that you bind the connection to is also important to remember since you will create it in the next section.

set ike gateway "vpn-boats-fb4" address 0.0.0.0 id "boat.example.com" Aggr outgoing-interface "redundant1" preshare "supersecret" proposal "vpn-boats-phase1"
 set vpn vpn-boats gateway vpn-boats replay proposal vpn-boats-phase-2 
 set vpn vpn-boats bind interface tunnel.1
 set vpn vpn-boats monitor optimized rekey

The second connection is almost the same but it contains NAT traversal and is using another incoming interface. The NAT traversal is enabled since I don’t get a public IP on the boat towards the internet.

 set ike gateway "vpn-boats-cellular" address 0.0.0.0 id "boat-dialup.example.com" Aggr outgoing-interface "redundant2" preshare "supersecret" proposal "vpn-boats-phase1"
 set ike gateway vpn-boats-cellular nat-traversal
 set vpn vpn-boats-cellular gateway vpn-boats-cellular replay proposal vpn-boats-phase-2 
 set vpn vpn-boats-cellular bind interface tunnel.2
 set vpn vpn-boats-cellular monitor optimized rekey
 unset vpn vpn-boats-cellular dscp-mark

The last thing needed before getting the connection up on the VPN tunnel is creating the tunnel interfaces.Remember to choose the address that you are peering with on the BGP and the tunnel number you did bind in the previous section

 set interface tunnel.1 zone vpn-boats
 set interface tunnel.1 ip 10.0.111.1/30
set interface tunnel.1 protocol bgp
set interface tunnel.1 protocol ping
 set interface tunnel.2 zone vpn-boats
set interface tunnel.2 ip 10.0.111.5/30
set interface tunnel.2 protocol bgp
set interface tunnel.2 protocol ping

Now your tunnel should be UP and running and you can do a ping test to verify the connection between them. We will now start on the final part that is the BGP configuration. I am expecting that the BGP config on the device itself is done when writing this so I wont include all the BGP configuration. Only the important part 🙂

I’m beginning with creating the route-map to prepend the traffic over the VPN. The route map will be named internet-prepend. The AS number on the local router is 64500.

set vrouter trust-vr
 set route-map name internet-prepend permit 1
 set match ip 20 10
 set as-path 12
 exit
set protocol bgp 64500
 set as-path-access-list 12 permit "64500 64500"

Then I will start configuring the neighbor connections. The first will be the BGP going over the internet and is having the prepend enabled. The rest of the configuration is straight forward.

set neighbor 10.0.111.6 remote-as 64501 local-ip 10.0.111.5/30
set neighbor 10.0.111.6 activate
set neighbor 10.0.111.6 force-reconnect
set neighbor 10.0.111.6 nhself-enable
set neighbor 10.0.111.6 reject-default-route
set neighbor 10.0.111.6 enable
set neighbor 10.0.111.6 route-map internet-prepend out

Then it’s the last BGP connection. It’s almost the same as the previous one except for the prepend.

set neighbor 10.0.111.2 remote-as 64501 local-ip 10.0.111.1/30
set neighbor 10.0.111.2 activate
set neighbor 10.0.111.2 force-reconnect
set neighbor 10.0.111.2 nhself-enable
set neighbor 10.0.111.2 reject-default-route
set neighbor 10.0.111.2 enable

That is all. If you have any questions or comments you can leave one in the comments section below.

Advertisement

Problems with NSM after schema upgrade.

Nils Magnus EliassenLeave a comment

The other day we upgraded the schema on our NSM server from 327 to 329. After the upgrade the devices was not able to connect to our NSM anymore. In the deviceDeamon I got the following error:

[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.

I didn’t know that a simple schema upgrade could do something to the NSM that would not allow the devices to connect so I ended up contacting JTAC support. When I got a support engineer and explained him the issue he found another error message in the guiDaemon. The error was “DC not connected”.

After a while with troubleshooting the engineer discovered that the issue was the RSA key that is responsible for the communication between the NSM services  and the guiDaemon and devDaemon. The engineer then navigated to devSvr.cfg under /usr/netscreen/DevSvr/var and deleted the RSA keys (ourRsaPrivateKey and theirRsaPublicKey).

After that all the devices in some magical way connected again!

Secondary node locked when commiting

Nils Magnus EliassenLeave a comment

The other day I got a problem with one of my SRX clusters when I was running a commit. The commit was not able to complete and I got the following error:

{primary:node0}[edit]
srx1400# commit
node1:
error: configuration database modified
node0:
error: remote lock-configuration failed on node1

The reason for this error is some uncommited configuration on the secondary node. Earlier the same day I changed the primary for redundancy-group 0 and I guess that I didn’t commit all the config on node1 before changing to node0.

To solve this I had to go into the secondary node (node1) and rollback the uncommitted configuration. Normally you can use OOB to connect to the secondary node but I dont have it at this location. So I have to connect to the secondary node trough the primary node. This is done with the following command on branch devices (SRX650 and below):  request routing-engine login node 1
On High end devices like the one I’m working on (SRX1400 and above) you use: rlogin -T node1

{secondary:node1}% rlogin -T node1
root@srx1400>
--- JUNOS 11.4R9.4 built 2013-08-22 06:24:21 UTC
{secondary:node1}
root@srx1400> configure
warning: Clustering enabled; using private edit
error: shared configuration database modified

Please temporarily use 'configure shared' to commit
outstanding changes in the shared database, exit,
and return to configuration mode using 'configure'

As you can see from the error I have to use configure shared to be able to edit the configuration.

root@srx1400> configure shared
Entering configuration mode
The configuration has been changed but not committed

Before entering the rollback command you can check the uncommitted configuration by running show | compare. This will display all the uncommited configuration

{secondary:node1}[edit]
root@srx1400# show | compare
[edit access profile unos clientjunos]
- pap-password "$9$2V4GDikP5T3fTrvLXwsz36C0B"; ## SECRET-DATA
+ pap-password "$9$jhHP5QF/CA09AxdsYGUp0BRyl"; ## SECRET-DATA

Now you can rollback the uncommited config, check that there is any uncommited config left and exit the configuration mode.

{secondary:node1}[edit]
root@rx1400# rollback
load complete

{secondary:node1}[edit]
root@srx1400# show | compare

{secondary:node1}[edit]
root@srx1400# exit
Exiting configuration mode

{secondary:node1}
root@srx1400>

Now you can close the session and try to commit the configuration from the primary node again. It worked for me! 🙂

As a note I also know that alot of people has had a success of using just the command commit synchronize force on the primary node but it does not work for everyone.

Bandwidth limiter in Junos

Nils Magnus EliassenLeave a comment

Today I had to limit a internet connection on one of the sites for the company I work for. The internet connection is mainly used for guest access and backup since the main traffic travels over a MPLS connection. The same internet connection was going to be used for a VPN tunell towards a supplier that has a VPN device behind my SRX240. Since this location is in the middle of nowhere it’s limited to 1 Mbps SDSL connection. The issue then is that there is no bandwidth left for the external VPN on the connection when guest users are using the connection.

I have added the main information regarding the configuration below:
Guest subnet: 192.168.200.0/26
Guest interface: vlan.20

The first step is to define the policer. Since I want to keep some bandwidth for the VPN I limit the 1 mbps to 800 kbps. As you can see from the text below there is an abbreviation for kbps that is k. You can specify a value in bits per second either as a complete decimal number or as a decimal number followed by the abbreviation k (1000),m (1,000,000), or g (1,000,000,000). You can also specify a value in cells per second by entering a decimal number followed by the abbreviation c; values expressed in cells per second are converted to bits per second using the formula 1 cps = 384 bps. The value can be any positive integer. In this example its set to 800 k.

set firewall policer policer-800k if-exceeding bandwidth-limit 800k
set firewall policer policer-800k if-exceeding burst-size-limit 625k
set firewall policer policer-800k then discard

The next part is to set the filter itself. Here I wan’t to configure the same speed limit both for up and down traffic. You can create diffrent limits for the different directions if you want to but in this example I have the same speed both ways. In the end of the filter I have a accept all to let the remaining traffic go trough the interface. I did not need to do that in this example but I like to make sure I don’t block anything that I shouldnt.

set firewall filter meeting-limit term from-meeting from source-address 192.168.200.0/26
set firewall filter meeting-limit term from-meeting then policer policer-800k
set firewall filter meeting-limit term from-meeting then accept
set firewall filter meeting-limit term to-meeting from destination-address 192.168.200.0/26
set firewall filter meeting-limit term to-meeting then policer policer-800k
set firewall filter meeting-limit term to-meeting then accept
set firewall filter meeting-limit term accept then accept

In the end we have to apply the filter to an interface as both inbound and outbound. The best practice is to only do this on the inbound side so you don’t process the traffic that you are discarding. In my case I had some issues with that. If I had filtered the traffic from the internet towards 192.168.200.0/26 network I wouldnt filter anything. The reason for this is that the traffic I would see is the NAT’ed address on the internet. So the destination adress would be my public IP. When I filter the outbound traffic on the port after it has returned trough NAT it get’s the correct IP and I can filter the traffic.

set interfaces vlan unit 20 description meetingroom
set interfaces vlan unit 20 family inet filter input meeting-limit
set interfaces vlan unit 20 family inet filter output meeting-limit
set interfaces vlan unit 20 family inet address 192.168.200.1/26

The configuration should in the end look something like this:

firewall {
	policer policer-800k {
		if-exceeding {
			bandwidth-limit 800k;
			burst-size-limit 625k;
		}
		then discard;
	}
}
filter meeting-limit {
    term from-meeting {
        from {
            source-address {
                192.168.200.0/26;
            }
        }
        then {
            policer policer-800k;
            accept;
        }
    }
    term to-meeting {
        from {
            destination-address {
                192.168.200.0/26;
            }
        }
        then {
            policer policer-800k;
            accept;
        }
    }
    term accept {
        then accept;
    }
}

interfaces{
	vlan {
		unit 20 {
			description meetingroom;
			family inet {
				filter {
					input meeting-limit;
					output meeting-limit;
				}
				address 192.168.200.1/26;
			}
		}
	}
}

As a reference I used KB28161

dst-port error in NSM

Nils Magnus EliassenLeave a comment

I got a new error while updating a SRX650 from the Juniper Network and Security Manager. The error started after I upgraded the SRX650 to 12.1X47-D30. The error I got is shown below:

Error Code: 

Error Text:
   Update fails UpdateDevice Results
sanityCheckCmd Success.
lock Success.
GenerateEditConfig Failed .
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/12.1X47/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
   <rpc-error>
      <error-severity>error</error-severity>
      <error-info>
         <bad-element>dst-port</bad-element>
      </error-info>
      <error-message>syntax error</error-message>
   </rpc-error>
   <rpc-error>
      <error-severity>error</error-severity>
      <error-info>
         <bad-element>dst-port</bad-element>
      </error-info>
      <error-message>syntax error</error-message>
   </rpc-error>
</rpc-reply>


unlock  Success .


Error Details:
   

Logs:
<configuration>
  <version>12.1X47-D25.4</version>
  <system>
    <host-name>casur-srx650-cluster</host-name>
  </system>
  <security>
    <nat>
      <destination>
        <rule-set>
          <name>ca-camera</name>
          <rule>
            <name>camera-01-8200</name>
            <dest-nat-rule-match>
              <destination-port operation="delete">
                <name>8200</name>
              </destination-port>
              <destination-port operation="create">
                <dst-port>8200</dst-port>
              </destination-port>
            </dest-nat-rule-match>
          </rule>
        </rule-set>
      </destination>
    </nat>
  </security>
</configuration>

It’s saying that the destination nat section has problems setting the dst-port. For some reason it was deleting the value and creating it with a new command (dst-port).

I then checked the supported Junos versions on the NSM and I discovered that the last supported version was 12.1X47-D25. Did the downgrade and updated the OS in the NSM. Still the same error as before.

Spoke to JTAC and they informed me that this error was known and that it would help downgrading to D15. This was due to a changed command in Junos. I downgraded to D15 but still the same issue. Researched a bit myself and discovered that it was introduced between X46 and X47.

Earlier it had not been possible to downgrade the versions in NSM. But for some reason I was able to do it now. First from D30 to D25, and after that from X47D15 to X46D40. When I reached  X46D40 I was able to run the update and everything was working.

Could not connect to node1 : No route to host

Nils Magnus EliassenLeave a comment

Today I had some issues when working on a SRX650. We had to replace the Services and Routing Engine a few days ago. When I was supposed to get the cluster back online I got the following error message when trying to run a few of the commands on the device:

Could not connect to node1 : No route to host

I got this error when typing show interface ge-0/0/2. I also entered the command on the node1 so I felt it was a bit strange that node1 could not connect to node1.

The firewall was also saying that it was in a hold mode

{hold:node1}

So it was not showing as secondary or primary. It was keeping this status all the time and didn’t try to go to any other modes while the issue was occuring.

The reason for my issues was that I had not deleted all the default config from the new Service and Routing engine card that we got. My config was not correct for all the cluster ports since some of the ports in the cluster is dedicated to cluster services (on the SRX650 it is ge-0/0/0 (fxp0) and ge-0/0/0 (control plane)). These ports are not to be configured as network ports and that is the reason for my issues. When I deleted the config and set a default root authentication password everything was connected. When I did a commit from the primary node the config was correct on both devices and everything connected succesfully.

During my search on the internet I read that some people also forgot to set the reth-count and got the same error. The command to set the number of reth interfaces is:

set chassis cluster reth-count 4

A great source for more information is the following chapter of the book “Juniper SRX Series” written by Brad Woodberg and Rob Cameron.

http://chimera.labs.oreilly.com/books/1234000001633/ch07.html#activating_juniper_services_redundancy