JunosNotes

SRX VIRTUALISATION: Basics

noreply@blogger.com (junosblogg) — Wed, 3 Sep 2014 16:44:00 +1000

Virtualisation.

That got your attention didn't it! It's the big topic these days and in the SRX we can apply in several ways.

In the Juniper world we have VSYS on ScreenOS and LSYS for high end SRXs both of which allow the creation of logical firewalls with different administrative rights within a single box.

There is also Firefly Perimeter to consider (Eval for 60 day)
http://www.juniper.net/us/en/products-services/security/firefly-perimeter/#evaluation

Even though we can't use LSYS on a branch SRX device we can still set up logical routers called Routing Instances on them and then apply specific zones/interfaces to those Routing Instances thereby gaining some degree or virtualisation in the branch SRX.

Lets look at a simple example of how to apply this..

Lets say we have a single SRX serving 2 separate companies. We'll call them comp1 and comp2. Each has their own Internet connection and they don't want to share them.

We will create a separate routing instance for comp1 and assign the zones that comp1 uses to it.

Remember: A logical interface or zone can only exist in one routing instance.

Here is the diagram of what we will build..

Comp2 will use the default master routing instance - inet.0
Comp1 will use a new created routing instance called vr-comp1, which means its routing instance will be vr-comp1.inet.0

In both the inet.0 and the routing instance the ISP interfaces (fe-0/0/7 and fe-0/0/6) are DHCP clients of their respective ISPs and will propagate the ISP assigned DNS settings to their associated DHCP client pools.

Before we get into the config of the routing instance I just want to mention some things about DHCP.

Juniper recommends (http://kb.juniper.net/InfoCenter/index?page=content&id=KB26897) to use JDHCP rather than DHCP as this addresses providing DHCP to a client on a routing instance which is what we will be doing.

So, for example, whereas before we would have had this config for DHCP to serve clients on the SRX..

set system services dhcp pool 10.10.10.0/24 address-range low 10.10.10.50
set system services dhcp pool 10.10.10.0/24 address-range high 10.10.10.100
set system services dhcp pool 10.10.10.0/24 exclude-address 10.10.10.30
set system services dhcp pool 10.10.10.0/24 default-lease-time 86400
set system services dhcp pool 10.10.10.0/24 domain-name xyz.com
set system services dhcp pool 10.10.10.0/24 router 10.10.10.1
set system services dhcp propagate-settings fe-0/0/4.0

We now have this config..

set system services dhcp-local-server group dhcp-comp2 interface vlan.7

set access address-assignment pool pool-comp2 family inet network 10.10.10.0/24
set access address-assignment pool pool-comp2 family inet range range-comp1 low 10.10.10.50
set access address-assignment pool pool-comp2 family inet range range-comp1 high 10.10.10.100
set access address-assignment pool pool-comp2 family inet dhcp-attributes maximum-lease-time 86400
set access address-assignment pool pool-comp2 family inet dhcp-attributes domain-name xyz.com
set access address-assignment pool pool-comp2 family inet dhcp-attributes router 10.10.10.1
set access address-assignment pool pool-comp2 family inet dhcp-attributes propagate-settings fe-0/0/4.0

Also not the difference in the daemon that is running

DHCP..

blogger@SRX> show system processes | match dhcp
1264 ?? S      9:17.23 /usr/sbin/dhcpd -N

JDHCP..

blogger@SRX-CORE> show system processes | match dhcp
4494 ?? S      0:00.98 /usr/sbin/jdhcpd -N

CONFIG FOR INET.0

1) Setup the ISP interface as a DHCP client

set interfaces fe-0/0/7 unit 0 family inet dhcp-client update-server

2) Create the logical VLAN interface for the comp2 clients and assign to physical interface.

set vlans vlan-comp2 vlan-id 20
set vlans vlan-comp2 l3-interface vlan.20
set interfaces fe-0/0/4 unit 0 family ethernet-switching vlan members vlan-comp2
set interfaces vlan unit 20 family inet address 192.168.20.1/24

3) Create The DHCP pool for the comp2 clients

set access address-assignment pool pool-comp2 family inet network 192.168.20.0/24
set access address-assignment pool pool-comp2 family inet range range-comp1 low 192.168.20.50
set access address-assignment pool pool-comp2 family inet range range-comp1 high 192.168.20.100
set access address-assignment pool pool-comp2 family inet dhcp-attributes maximum-lease-time 86400
set access address-assignment pool pool-comp2 family inet dhcp-attributes domain-name comp2.com
set access address-assignment pool pool-comp2 family inet dhcp-attributes router 192.168.20.1
set access address-assignment pool pool-comp2 family inet dhcp-attributes propagate-settings fe-0/0/7.0

4) Set the default route for inet.0

Set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1

CONFIG FOR THE ROUTING INSTANCE.

1) Set up the ISP interface as a DHCP client

set interfaces fe-0/0/6 unit 0 family inet dhcp-client update-server

Note the use of the dhcp-client now rather than dhcp. Below is what happens if you don't

blogger@SRX-CORE# commit
[edit interfaces fe-0/0/6 unit 0 family inet]
'dhcp'
    Incompatible with the dhcp-local-server configured under 'routing-instances <*> system services dhcp-local-server group
[edit interfaces fe-0/0/6 unit 0 family inet]
'dhcp'
    Incompatible with the dhcp-local-server configured under 'system services dhcp-local-server group

2) Create the logical VLAN interface for the comp1 clients and assign to physical interface.

set vlans vlan-comp1 vlan-id 10
set vlans vlan-comp1 l3-interface vlan.10
set interfaces fe-0/0/3 unit 0 family ethernet-switching vlan members vlan-comp1
set interfaces vlan unit 10 family inet address 192.168.10.1/24

3) Create the routing instance and assign interfaces

set routing-instances vr-comp1 instance-type virtual-router
set routing-instances vr-comp1 interface fe-0/0/6.0
set routing-instances vr-comp1 interface vlan.10
set interfaces vlan unit 10 family inet address 192.168.10.1/24

4) Create The DHCP pool for the comp1 clients

set routing-instances vr-comp1 system services dhcp-local-server group dhcp-comp1 interface vlan.10
set routing-instances vr-comp1 access address-assignment pool pool-comp1 family inet network 192.168.10.0/24
set routing-instances vr-comp1 access address-assignment pool pool-comp1 family inet range range-comp1 low 192.168.10.50
set routing-instances vr-comp1 access address-assignment pool pool-comp1 family inet range range-comp1 high 192.168.10.100
set routing-instances vr-comp1 access address-assignment pool pool-comp1 family inet dhcp-attributes maximum-lease-time 86400
set routing-instances vr-comp1 access address-assignment pool pool-comp1 family inet dhcp-attributes domain-name comp.com
set routing-instances vr-comp1 access address-assignment pool pool-comp1 family inet dhcp-attributes router 192.168.10.1
set routing-instances vr-comp1 access address-assignment pool pool-comp1 family inet dhcp-attributes propagate-settings fe-0/0/6.0

5) Give the routing instance a default route

set routing-instances vr-comp1 routing-options static route 0.0.0.0/0 next-hop 2.2.2.2

Here is all the routing instance config..

blogger@SRX-CORE> show configuration routing-instances
vr-comp1 {
    instance-type virtual-router;
    system {
        services {
            dhcp-local-server {
                group dhcp-comp1 {
                    interface vlan.10;
                }
            }
        }
    }
    access {
        address-assignment {
            pool pool-comp1 {
                family inet {
                    network 192.168.10.0/24;
                    range range-comp1 {
                        low 192.168.10.50;
                        high 192.168.10.100;
                    }
                    dhcp-attributes {
                        maximum-lease-time 86400;
                        domain-name comp1.com;
                        router {
                            192.168.10.1;
                        }
                        propagate-settings fe-0/0/6.0;
                    }
                }
            }
        }
    }
    interface fe-0/0/6.0;
    interface vlan.10;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 2.2.2.2;
        }
    }
}

ZONE, NAT AND POLICY SETTINGS

set security zones security-zone zone-comp1 interfaces vlan.10 host-inbound-traffic system-services ping
set security zones security-zone zone-comp1 interfaces vlan.10 host-inbound-traffic system-services dhcp
set security zones security-zone zone-comp2 interfaces vlan.20 host-inbound-traffic system-services dhcp
set security zones security-zone zone-comp2 interfaces vlan.20 host-inbound-traffic system-services ping
set security zones security-zone zone-isp1 interfaces fe-0/0/6.0 host-inbound-traffic system-services dhcp
set security zones security-zone zone-isp2 interfaces fe-0/0/7.0 host-inbound-traffic system-services dhcp

set security nat source rule-set comp2-isp2 from zone zone-comp2
set security nat source rule-set comp2-isp2 to zone zone-isp2
set security nat source rule-set comp2-isp2 rule n1-comp2 match source-address 0.0.0.0/0
set security nat source rule-set comp2-isp2 rule n1-comp2 then source-nat interface
set security nat source rule-set comp1-isp1 from zone zone-comp1
set security nat source rule-set comp1-isp1 to zone zone-isp1
set security nat source rule-set comp1-isp1 rule n1-comp1 match source-address 0.0.0.0/0
set security nat source rule-set comp1-isp1 rule n1-comp1 then source-nat interface

set security policies from-zone zone-comp2 to-zone zone-isp2 policy p1-comp2 match source-address any
set security policies from-zone zone-comp2 to-zone zone-isp2 policy p1-comp2 match destination-address any
set security policies from-zone zone-comp2 to-zone zone-isp2 policy p1-comp2 match application any
set security policies from-zone zone-comp2 to-zone zone-isp2 policy p1-comp2 then permit
set security policies from-zone zone-comp2 to-zone zone-isp2 policy p1-comp2 then log session-init
set security policies from-zone zone-comp1 to-zone zone-isp1 policy p1-comp1 match source-address any
set security policies from-zone zone-comp1 to-zone zone-isp1 policy p1-comp1 match destination-address any
set security policies from-zone zone-comp1 to-zone zone-isp1 policy p1-comp1 match application any
set security policies from-zone zone-comp1 to-zone zone-isp1 policy p1-comp1 then permit
set security policies from-zone zone-comp1 to-zone zone-isp1 policy p1-comp1 then log session-init

As you can see, nothing special for these elements in relation to the routing instance.

VERIFICATION

1) Check the route instances

blogger@SRX-CORE> show route instance
Instance             Type
         Primary RIB                                     Active/holddown/hidden
master               forwarding
         inet.0                                          8/0/0
__juniper_private1__ forwarding
         __juniper_private1__.inet.0                     7/0/0

__juniper_private2__ forwarding
         __juniper_private2__.inet.0                     0/0/1

__master.anon__      forwarding

vr-comp1             virtual-router
         vr-comp1.inet.0                                 7/0/0

blogger@SRX-CORE> show route instance vr-comp1
Instance             Type
         Primary RIB                                     Active/holddown/hidden
vr-comp1             virtual-router
         vr-comp1.inet.0                                 7/0/0

2) Check the route tables

Notice the 2 now separate route tables

blogger@SRX-CORE> show route

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

0.0.0.0/0          *[Static/5] 04:04:15
                    > to 1.1.1.1 via fe-0/0/7.0
1.1.1.0/24         *[Direct/0] 04:04:15
                    > via fe-0/0/7.0
1.1.1.10/32        *[Local/0] 04:04:15
                      Local via fe-0/0/7.0
192.168.20.0/24    *[Direct/0] 04:06:40
                    > via vlan.20
192.168.20.1/32    *[Local/0] 5d 19:56:05
                      Local via vlan.20
192.168.20.51/32   *[Access-internal/12] 03:08:19
                    > to 192.168.20.1 via vlan.20

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

0.0.0.0/0          *[Static/5] 03:58:55
                    > to 2.2.2.2 via fe-0/0/6.0
2.2.2.0/24         *[Direct/0] 03:58:56
                    > via fe-0/0/6.0
2.2.2.10/32        *[Local/0] 03:58:56
                      Local via fe-0/0/6.0
192.168.10.0/24    *[Direct/0] 03:23:29
                    > via vlan.10
192.168.10.1/32    *[Local/0] 5d 19:56:05
                      Local via vlan.10
192.168.10.51/32   *[Access-internal/12] 03:31:51
                    > to 192.168.10.1 via vlan.10
192.168.10.52/32   *[Access-internal/12] 03:31:51
                    > to 192.168.10.1 via vlan.10

3) Verify inet.0 and the routing instance can both access the internet..

blogger@SRX-CORE> ping 8.8.8.8 count 4 rapid
PING 8.8.8.8 (8.8.8.8): 56 data bytes
!!!!
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 62.483/94.899/112.646/19.407 ms

blogger@SRX-CORE>

blogger@SRX-CORE> ping 8.8.8.8 routing-instance vr-comp1 count 4 rapid
PING 8.8.8.8 (8.8.8.8): 56 data bytes
!!!!
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.550/6.442/8.554/1.731 ms

blogger@SRX-CORE>

5) Verify DHCP client and Server

blogger@SRX-CORE> show dhcp client binding

IP address        Hardware address   Expires     State      Interface
1.1.1.10          40:b4:f0:8f:2d:47 72916       BOUND      fe-0/0/7.0

blogger@SRX-CORE> show dhcp client binding routing-instance vr-comp1

IP address        Hardware address   Expires     State      Interface
2.2.2.10          40:b4:f0:8f:2d:46 72909       BOUND      fe-0/0/6.0

blogger@SRX-CORE> show dhcp server binding detail

Client IP Address: 192.168.20.51
     Hardware Address:             08:00:27:ce:af:e7
     State:                        BOUND(LOCAL_SERVER_STATE_BOUND)
     Lease Expires:                2014-09-04 11:04:55 UTC
     Lease Expires in:             74229 seconds
     Lease Start:                  2014-09-03 11:04:55 UTC
     Last Packet Received:         2014-09-03 11:04:55 UTC
     Incoming Client Interface:    vlan.20
     Client Interface Vlan Id:     20
     Server Identifier:            192.168.20.1
     Session Id:                   7
     Client Pool Name:             pool-comp2

blogger@SRX-CORE> show dhcp server binding detail routing-instance vr-comp1

Client IP Address: 192.168.10.52
     Hardware Address:             00:23:18:46:37:85
     State:                        BOUND(LOCAL_SERVER_STATE_BOUND)
     Lease Expires:                2014-09-04 10:49:51 UTC
     Lease Expires in:             73299 seconds
     Lease Start:                  2014-09-03 10:49:51 UTC
     Last Packet Received:         2014-09-03 10:49:59 UTC
     Incoming Client Interface:    vlan.10
     Client Interface Vlan Id:     10
     Server Identifier:            192.168.10.1
     Session Id:                   6
     Client Pool Name:             pool-comp1
Client IP Address: 192.168.10.51
     Hardware Address:             00:23:18:46:37:85
     State:                        BOUND(LOCAL_SERVER_STATE_BOUND)
     Lease Expires:                2014-09-04 10:06:43 UTC
     Lease Expires in:             70711 seconds
     Lease Start:                  2014-09-03 10:06:43 UTC
     Last Packet Received:         unknown
     Incoming Client Interface:    vlan.10
     Client Interface Vlan Id:     10
     Server Identifier:            192.168.10.1
     Session Id:                   5
     Client Pool Name:             pool-comp1


So that's it. Two separate client groups using 2 different Internet links on one SRX.
All DHCP client , server and propagation is working with this config.

This is one way to do it. There are of course different ways....

Model: srx210he
JUNOS Software Release [12.1X44-D35.5]

SRX IDP: Templates Update

noreply@blogger.com (junosblogg) — Mon, 14 Jul 2014 16:11:00 +1000

Did you notice that Juniper has updated their IDP policy templates?

First lets review the list of old of pre-defined templates..

blogger@SRX> show security idp policy-templates-list
Web_Server
DMZ_Services
DNS_Service
File_Server
Getting_Started
IDP_Default
Recommended

Lets check the version of that template..

blogger@SRX> show security idp security-package-version
Attack database version:2395(Wed Jul 2 18:14:04 2014 UTC)
Detector version :12.6.160140626
Policy template version :2192

Lets check and see whats available..

blogger@SRX> request security idp security-package download check-server
Successfully retrieved from(https://services.netscreen.com/cgi-bin/index.cgi).
Version info:2395(Detector=12.6.160140626, Templates=2395)

So you see, even if you are automatically updating the attack database that doesn't update the policy templates.

GETTING THE NEW TEMPLATES.

Using the same process that I described before in my IDP blog..

a) Download the templates

blogger@LEFTY> request security idp security-package download policy-templates
Will be processed in async mode. Check the status using the status checking CLI

blogger@SRX> request security idp security-package download status
Done;Successfully downloaded from(https://services.netscreen.com/cgi-bin/index.cgi).
Version info:2395

b) Install the templates

blogger@SRX> request security idp security-package install policy-templates
Will be processed in async mode. Check the status using the status checking CLI

blogger@SRX> request security idp security-package install status
Done;policy-templates has been successfully updated into internal repository
     (=>/var/db/scripts/commit/templates.xsl)!

c) Install and then delete the script

blogger@SRX# set system scripts commit file templates.xsl

[edit]
blogger@SRX# commit
commit complete

[edit]
blogger@SRX# delete system scripts

[edit]
blogger@SRX# commit
commit complete

As always this step takes time and will likely drive your cpu to close to 100% on a low end device

d) check the version..

blogger@SRX> show security idp security-package-version
Attack database version:2395(Wed Jul 2 18:14:04 2014 UTC)
Detector version :12.6.160140626
Policy template version :2395

Our policy templates are now updated.

e) Examine the available templates..

blogger@SRX> show security idp policy-templates-list
Web_Server
DMZ_Services
DNS_Service
File_Server
Getting_Started
IDP_Default
Recommended
Server-Protection
Server-Protection-1G
Client-Protection
Client-Protection-1G
Client-And-Server-Protection
Client-And-Server-Protection-1G

A few new templates to consider there.

Here are the descriptions that come with each template..

idp-policy Web_Server {
    /* This template policy is designed to protect commonly used HTTP servers from remote attacks. */

idp-policy DMZ_Services {
    /* This template policy is designed to be used to protect a typical DMZ environment. */

idp-policy DNS_Service {
    /* This template policy is designed to protect DNS services. Use this template as a starting point to customize your desired level of protection. */

idp-policy File_Server {
    /* This template policy is designed to provide protection to various file sharing services such as AMB, NFS, FTP, and others. */

idp-policy Getting_Started {
    /* This template is a good starting point for learning how to create IDP policies. */

idp-policy IDP_Default {
    /* This template policy represents a good blend od security and performance. Use this template for "in-line" mode. */

idp-policy Recommended {
    /* This legacy template policy covers most current vulnerabilities. This template is supported on all platforms, including Branch devices with 1G of memory. */

idp-policy Server-Protection {
    /* This template policy is designed to protect servers. It is supported on devices with 2G or more of memory. Branch devices with only 1G are not supported. */

idp-policy Server-Protection-1G {
    /* This template policy is designed to protect servers. This template is supported on all platforms, including Branch devices with 1G of memory. */

idp-policy Client-Protection {
    /* This template policy is designed to protect clients. It is supported on devices with 2G or more of memory. Branch devices with only 1G are not supported. */

idp-policy Client-Protection-1G {
    /* This template policy is designed to protect clients. This template is supported on all platforms, including Branch devices with 1G of memory. */

idp-policy Client-And-Server-Protection {
    /* This template policy is designed to protect both clients and servers. It is supported on devices with 2G or more of memory. Branch devices with only 1G are not supported. */

idp-policy Client-And-Server-Protection-1G {
    /* This template policy is designed to protect both clients and servers. This template is supported on all platforms, including Branch devices with 1G of memory. */

Interesting that they call the Recommended policy now "Legacy" and I note that the Recommended template as it now comes seems to have all its rules duplicated; first as numbered and then as named rules. I guess if you wanted to use this new Recommended template you would delete which ever lot of either the named or numbered you didn't want.

ACTIVATE A POLICY

a) Copy the template you wish to use.

Make a copy of the template you wish to use as a starting point, so you can always reference where you came from and what you changed in your own policy from the default.

Eg..

blogger@SRX# copy security idp idp-policy Client-Protection-1G to idp-policy Client-Protection-1G_customised

[edit]
blogger@SRX# commit
commit complete

b) Activate the new policy

blogger@SRX# set security idp active-policy Client-Protection-1G_customised

[edit]
blogger@SRX# commit
commit complete

blogger@SRX> show security idp status
State of IDP: Default, Up since: 2014-06-06 10:16:46 EST (4w0d 06:15 ago)

Packets/second: 22              Peak: 852 @ 2014-06-27 16:01:42 EST
KBits/second : 52              Peak: 5377 @ 2014-07-04 16:20:13 EST
Latency (microseconds): [min: 0] [max: 0] [avg: 0]

Packet Statistics:
[ICMP: 0] [TCP: 4364406] [UDP: 159154] [Other: 0]

Flow Statistics:
ICMP: [Current: 0] [Max: 714 @ 2014-06-17 14:05:40 EST]
TCP: [Current: 58] [Max: 698 @ 2014-06-17 13:59:43 EST]
UDP: [Current: 0] [Max: 1574 @ 2014-07-03 12:40:43 EST]
Other: [Current: 0] [Max: 0 @ 2014-06-06 10:16:46 EST]

Session Statistics:
[ICMP: 0] [TCP: 29] [UDP: 0] [Other: 0]
Policy Name : Client-Protection-1G_customised
Running Detector Version : 12.6.160140626

blogger@SRX>

c) Delete the other policies from the configuration for a cleanup

CHANGE POLICIES

What if you wanted to change the active IDP policy to another template after you deleted all the other ones from the config?

It can be done.

The old templates are still there for you even if they are not in the config (I.e if you did a cleanup) but you cant just switch to another one if its not in the config. Eg..

[edit]
root# set security idp active-policy Recommended

[edit]
root# commit
[edit security idp active-policy]
'active-policy Recommended'
    Policy must be defined under [security idp idp-policy]
error: commit failed: (statements constraint check failed)

[edit]
root#

So if you wanted to resurrect one of the templates you deleted from the policy just commit the templates script again and select activate the policy template you want.

[edit]
root# set system scripts commit file templates.xsl

[edit]
root# commit
commit complete

[edit]
root# delete system scripts

[edit]
root# commit
commit complete

[edit]

Doing this will of course bring all the templates back into the config and also wont delete your customised template copy policy.

SUMMARY

If you using an old template its worth having a look at the new ones as a basis for starting off or just for giving you ideas of rules to add to your existing policy.

Model: srx210he
JUNOS Software Release [12.1X44-D25.5]

SRX NAT: Destination

noreply@blogger.com (junosblogg) — Tue, 29 Apr 2014 16:41:00 +1000

Today we will have a look at some Destination NAT (DNAT) on the SRX with port translation.

We have the following network scenario..

In the this scenario we need to do DNAT using the actual external interface IP (192.168.200.200).

So the flows will go like this..

PRENAT                                         POSTNAT
192.168.200.10 --> 192.168.200.200:8088        192.168.200.10 --> 10.31.254.17:80
192.168.200.10 --> 192.168.200.200:2088       192.168.200.10 --> 10.31.254.17:22

DNAT is a one way translation. It does not itself permit the destination to initiate to the source.
The destination can of course statefully reply to a session initiated to it.

Steps to configure and test..

1) CREATE ADDRESS ENTRIES

The only address book entry we need is the real IP of the destination

srx> show configuration security address-book | display set | match 10.31.254.17
set security address-book global address SERVER_REAL_10.31.254.17 10.31.254.17/32

2) CREATE DNAT RULES

srx> show configuration security nat destination | display set
set security nat destination pool TESTA address 10.31.254.17/32
set security nat destination pool TESTA address port 80
set security nat destination pool TESTA_2 address 10.31.254.17/32
set security nat destination pool TESTA_2 address port 22
set security nat destination rule-set DNAT1 from zone untrust
set security nat destination rule-set DNAT1 rule r1 match destination-address 192.168.200.200/32
set security nat destination rule-set DNAT1 rule r1 match destination-port 8088
set security nat destination rule-set DNAT1 rule r1 then destination-nat pool TESTA
set security nat destination rule-set DNAT1 rule r2 match destination-address 192.168.200.200/32
set security nat destination rule-set DNAT1 rule r2 match destination-port 2088
set security nat destination rule-set DNAT1 rule r2 then destination-nat pool TESTA_2

Looks like this in the heirachical config..

srx> show configuration security nat destination
pool TESTA {
    address 10.31.254.17/32 port 80;
}
pool TESTA_2 {
    address 10.31.254.17/32 port 22;
}
rule-set DNAT1 {
    from zone untrust;
    rule r1 {
        match {
            destination-address 192.168.200.200/32;
            destination-port 8088;
        }
        then {
            destination-nat pool TESTA;
        }
    }
    rule r2 {
        match {
            destination-address 192.168.200.200/32;
            destination-port 2088;
        }
        then {
            destination-nat pool TESTA_2;
        }
    }
}

3) CREATE SECURITY POLICIES

The main point to note here is that we use the translated destination IP in the rule as DNAT takes place before the security policy is processed. Also the port to be used is the post translation destination port.

srx> show configuration security policies from-zone untrust to-zone trust | display set
set security policies from-zone untrust to-zone trust policy p1 match source-address any
set security policies from-zone untrust to-zone trust policy p1 match destination-address SERVER_REAL_10.31.254.17
set security policies from-zone untrust to-zone trust policy p1 match application junos-http
set security policies from-zone untrust to-zone trust policy p1 then permit destination-address drop-untranslated
set security policies from-zone untrust to-zone trust policy p1 then log session-init
set security policies from-zone untrust to-zone trust policy p2 match source-address any
set security policies from-zone untrust to-zone trust policy p2 match destination-address SERVER_REAL_10.31.254.17
set security policies from-zone untrust to-zone trust policy p2 match application junos-ssh
set security policies from-zone untrust to-zone trust policy p2 then permit destination-address drop-untranslated
set security policies from-zone untrust to-zone trust policy p2 then log session-init

Looks like this in the heirachical config..

srx> show configuration security policies from-zone untrust to-zone trust
policy p1 {
    match {
        source-address any;
        destination-address SERVER_REAL_10.31.254.17;
        application junos-http;
    }
    then {
        permit {
            destination-address {
                drop-untranslated;
            }
        }
        log {
            session-init;
        }
    }
}
policy p2 {
    match {
        source-address any;
        destination-address SERVER_REAL_10.31.254.17;
        application junos-ssh;
    }
    then {
        permit {
            destination-address {
                drop-untranslated;
            }
        }
        log {
            session-init;
        }
    }
}

We have the source set as any as the source in these types of rules is often coming from the Internet.
For extra security we are only permitting packets that are subjected to being translated - "drop-untranslated"

4) TESTING

a) Checking if our DNAT rules have hits..

srx> show security nat destination rule all
Total destination-nat rules: 2
Total referenced IPv4/IPv6 ip-prefixes: 2/0

Destination NAT rule: r1                   Rule-set: DNAT1
Rule-Id                    : 1
Rule position              : 1
From zone                  : untrust
    Destination addresses    : 192.168.200.200 - 192.168.200.200

Destination port           : 8088
Action                     : TESTA
Translation hits           : 44

Destination NAT rule: r2                   Rule-set: DNAT1
Rule-Id                    : 2
Rule position              : 2
From zone                  : untrust
    Destination addresses    : 192.168.200.200 - 192.168.200.200

Destination port           : 2088
Action                     : TESTA_2
Translation hits           : 3

b) Checking if the security policy rules have hits..

srx> show security policies hit-count from-zone untrust to-zone trust
Logical system: root-logical-system
Index   From zone        To zone           Name           Policy count
1       untrust          trust             p1             44
2       untrust          trust             p2             3

Number of policy: 2

c) We should see active flow sessions..

srx> show security flow session source-prefix 192.168.200.10
Session ID: 24519, Policy name: p2/7, Timeout: 1780, Valid
In: 192.168.200.10/35673 --> 192.168.200.200/2088;tcp, If: vlan.3, Pkts: 67, Bytes: 5762
Out: 10.31.254.17/22 --> 192.168.200.10/35673;tcp, If: vlan.2, Pkts: 45, Bytes: 5629

Session ID: 24794, Policy name: p1/6, Timeout: 1194, Valid
In: 192.168.200.10/54017 --> 192.168.200.200/8088;tcp, If: vlan.3, Pkts: 30, Bytes: 5251
Out: 10.31.254.17/80 --> 192.168.200.10/54017;tcp, If: vlan.2, Pkts: 27, Bytes: 29397

d) Finally we can also check the logs as we are logging on "session-init"
In the below you can clearly see the pre nat dest IP being DNATed to the post nat IP in the initial session setup..

srx> show log POLICY | match 192.168.200.10
Apr 29 14:49:19   RT_FLOW: RT_FLOW_SESSION_CREATE: session created 192.168.200.10/35673->192.168.200.200/2088 junos-ssh 192.168.200.10/35673->10.31.254.17/22 None r2 6 p2 untrust trust 24519 N/A(N/A) vlan.3
Apr 29 14:49:56   RT_FLOW: RT_FLOW_SESSION_CREATE: session created 192.168.200.10/54017->192.168.200.200/8088 junos-http 192.168.200.10/54017->10.31.254.17/80 None r1 6 p1 untrust trust 24794 N/A(N/A) vlan.3

5) PROXY ARP

In the above example I have not used proxy arp as we are using the actual interface address as the initial target for the source. But what if the destination address was 192.168.200.201 rather than the interface's IP of 192.168.200.200.

I.e What if we changed NAT rule r1 to be like this?

rule-set DNAT1 {
    from zone untrust;
    rule r1 {
        match {
            destination-address 192.168.200.201/32;
            destination-port 8088;
        }
        then {
            destination-nat pool TESTA;
        }
    }

Then in this case we do need proxy-arp as we meet this criteria as defined by Juniper in KB21785 http://kb.juniper.net/InfoCenter/index?page=content&id=KB21785

"When addresses in the original destination address entry in the destination NAT rules are in the same subnet as that of the ingress interface   (Destination NAT scenario)"

This is what we need to make it work..
set security nat proxy-arp interface vlan.3 address 192.168.200.201/32

vlan.3 in our case is the untrust VLAN.

Model: srx210he
JUNOS Software Release [12.1R5.5]

CX111

noreply@blogger.com (junosblogg) — Mon, 17 Feb 2014 12:47:00 +1100

I recently had the opportunity to test out a CX111.
Its a device that acts as a L2 bridge between a 3G/4G USB modem connected to one of 3 available USB ports on it and a single Ethernet port.

http://www.juniper.net/au/en/products-services/routing/srx-series/cx111/

Specifically I tested it with a Telstra 4G Sierra Wireless AirCard 320U.
And the results were great!

My setup was as follows..
Telstra 4G USB ----CX111----SRX----laptop
The 4G USB stick was plugged into USB1 of the CX111.
The SRX on the CX111 side was set to the untrust zone and on the client side the trust zone.

The only things I had to do on the CX111 to get it connected to the Telstra network were:
a) Upgrade the firmware from 1.7.2 to 2.2.2 which was easily done through the CX111 gui.

b) Program the SIM PIN of the USB into CX111.

That's it! After that the Telstra 4G USB stick successfully connected to the network. Too easy..

The CX111 has a 2 position switch on it. In the "O" position the CX111 assigns a locally set DHCP assignment downstream to it's LAN connected device. This is known as configuration mode, though its still usable as a WAN device when set this way - its just that you can manage it as well from it's LAN side.

When the switch is set to the "I" position it's in Pass-Through mode and CX111 LAN side device receives the ISP IP assignment.

The only gotcha is that the CX111 will not propagate the ISP DNS settings in its DHCP assignment to the SRX (Or whatever is on it's LAN interface) regardless of which way the switch is set. So you must hard set the DNS for the SRX trust zone DHCP pool within the SRX config.

Conclusion - a quick and easy way to bring 4G data services to a site as either a primary or backup WAN service.

Here is the relevant parts of the config of the SRX to get it going.

set system services dhcp pool 192.168.40.0/24 address-range low 192.168.40.40
set system services dhcp pool 192.168.40.0/24 address-range high 192.168.40.210
set system services dhcp pool 192.168.40.0/24 default-lease-time 86400
set system services dhcp pool 192.168.40.0/24 name-server 10.4.81.103
set system services dhcp pool 192.168.40.0/24 router 192.168.40.1

set interfaces ge-0/0/0 unit 0 family inet dhcp
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members vlan-trust
set interfaces fe-0/0/2 unit 0 family ethernet-switching vlan members vlan-trust
set interfaces fe-0/0/3 unit 0 family ethernet-switching vlan members vlan-trust
set interfaces fe-0/0/4 unit 0 family ethernet-switching vlan members vlan-trust
set interfaces fe-0/0/5 unit 0 family ethernet-switching vlan members vlan-trust
set interfaces fe-0/0/6 unit 0 family ethernet-switching vlan members vlan-trust
set interfaces fe-0/0/7 unit 0 family ethernet-switching vlan members vlan-trust
set interfaces vlan unit 2 family inet address 192.168.40.1/24

set security nat source rule-set trust_to_untrust from zone trust
set security nat source rule-set trust_to_untrust to zone untrust
set security nat source rule-set trust_to_untrust rule source_nat_trust match source-address 0.0.0.0/0
set security nat source rule-set trust_to_untrust rule source_nat_trust then source-nat interface

set security policies from-zone trust to-zone untrust policy p1 match source-address any
set security policies from-zone trust to-zone untrust policy p1 match destination-address any
set security policies from-zone trust to-zone untrust policy p1 match application any
set security policies from-zone trust to-zone untrust policy p1 then permit
set security policies from-zone trust to-zone untrust policy p1 then log session-init

set security zones security-zone trust host-inbound-traffic system-services all
set security zones security-zone trust host-inbound-traffic protocols all
set security zones security-zone trust interfaces vlan.2
set security zones security-zone untrust screen untrust-screen
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services dhcp
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ping

set vlans vlan-trust vlan-id 2
set vlans vlan-trust l3-interface vlan.2

SRX VPN: Multipoint

noreply@blogger.com (junosblogg) — Fri, 3 Jan 2014 10:38:00 +1100

Happy New Year to all readers!

Today we are going to make a multipoint VPN.
One hub site (VPN-CORE) and 2 spokes sites (LEFTY and RIGHTY2). All devices are SRXs.

Multipoint is only supported with Route based VPNs so that's what we will be using and the key point to note is that the multipoint hub only uses a single tunnel interface regardless of the number of VPN tunnels.

In real life you probably wouldn't bother with multipoint for just 2 spokes but this is a lab so lets do it!

Here is the network we are working on..
We will want to get traffic between the 2 trust zones and the server-zone running over the VPN.

SPOKE SITE CONFIG (RIGHTY2)

With colour highlights showing how all the different elements "glue" together.

1) TUNNEL INTERFACE

Create the tunnel interface.
All the tunnel interfaces are in the same subnet - 20.0.20.0/24

set interfaces st0 unit 0 family inet address 20.0.20.3/24

2) ROUTING

a) Define default route to point to the cloud.

set routing-options static route 0.0.0.0/0 next-hop 3.3.3.1

b) Define which destination traffic we wish to access to via the tunnel interface.

We wish to get to the server network behind VPN-CORE via the VPN,

set routing-options static route 192.168.210.0/24 next-hop st0.0

3) SPOKE CONFIG PHASE 1 and 2

a) Define Phase 1 proposal set

set security ike proposal aes-phase1 authentication-method pre-shared-keys
set security ike proposal aes-phase1 dh-group group2
set security ike proposal aes-phase1 authentication-algorithm sha1
set security ike proposal aes-phase1 encryption-algorithm aes-256-cbc
set security ike proposal aes-phase1 lifetime-seconds 86400

b) Define Phase 1 policy

set security ike policy hub_p1_pol mode main
set security ike policy hub_p1_pol proposals aes-phase1
set security ike policy hub_p1_pol pre-shared-key ascii-text testkey2

c) Define Phase 1 gateway

set security ike gateway hub_gw ike-policy hub_p1_pol
set security ike gateway hub_gw address 4.4.4.2
set security ike gateway hub_gw external-interface fe-0/0/7.0
set security ike gateway hub_gw version v1-only

The IP address here is the external address of the hub SRX ans the external interface in the physical interface the VPN traffic will use

d) Define Phase 2 proposal set

set security ipsec proposal aes-phase2 protocol esp
set security ipsec proposal aes-phase2 authentication-algorithm hmac-sha1-96
set security ipsec proposal aes-phase2 encryption-algorithm aes-256-cbc
set security ipsec proposal aes-phase2 lifetime-seconds 3600

e) Define Phase 2 policy

set security ipsec policy hub_p2_pol perfect-forward-secrecy keys group2
set security ipsec policy hub_p2_pol proposals aes-phase2

f) Define the VPN

set security ipsec vpn hub_vpn bind-interface st0.0
set security ipsec vpn hub_vpn ike gateway hub_gw
set security ipsec vpn hub_vpn ike ipsec-policy hub_p2_pol
set security ipsec vpn hub_vpn establish-tunnels immediately

You can clearly see how the VPN section of the config ties all the other elements together

So no difference in configuring the spoke side of a multipoint VPN as compared to configuring one side of a point-to-point link.

4) VPN ZONE

Define a VPN security zone and put the tunnel interface in it.

set security zones security-zone vpn interfaces st0.0

5) ADDRESSES

Define any needed addresses for the policy rules

Local address..

set security address-book global address net_192.168.197.0/24 192.168.197.0/24

Remote address..

set security address-book global address net_192.168.210.0/24 192.168.210.0/24

6) POLICY

Create appropriate policy rules according to your needs

From the local network to the remote server network on any port

set security policies from-zone trust to-zone vpn policy vpn_core_access match source-address net_192.168.197.0/24
set security policies from-zone trust to-zone vpn policy vpn_core_access match destination-address net_192.168.210.0/24
set security policies from-zone trust to-zone vpn policy vpn_core_access match application any
set security policies from-zone trust to-zone vpn policy vpn_core_access then permit
set security policies from-zone trust to-zone vpn policy vpn_core_access then log session-init

From the remote server network to the local network on any port

set security policies from-zone vpn to-zone trust policy vpn_core_access match source-address net_192.168.210.0/24
set security policies from-zone vpn to-zone trust policy vpn_core_access match destination-address net_192.168.197.0/24
set security policies from-zone vpn to-zone trust policy vpn_core_access match application any
set security policies from-zone vpn to-zone trust policy vpn_core_access then permit
set security policies from-zone vpn to-zone trust policy vpn_core_access then log session-init

7) ALLOW IKE

Permit IKE on the external facing security zone

set security zones security-zone cloud-link host-inbound-traffic system-services ike

HUB SITE CONFIG (VPN-CORE)

1) TUNNEL INTERFACE

set interfaces st0.0 multipoint family inet address 20.0.20.4/24

* Note the use of the keywork Multipoint. This is the only tunnel interface we will need to create on the hub site. Which leads us to..

NHTB.

The hub device has only one tunnel interface in a multipoint config so it needs a way to be able to decide which VPN to use for what traffic.

For this it uses the next-hop tunnel binding table (NHTB) feature which maps VPN names to next hop IP gateways. VPN name in this instance means the actual name given in the set security ipsec vpn command. The remote device's st0 interface IP is the next hop IP for the NHTB

Here are the elements to get traffic into the correct tunnel for a specific destination address.
inet.0     - destination address to next hop mapping
NHTB     - next hop mapping to VPN ....i.e The link between the destination route and the VPN to use for that route

As all the devices in our network are SRXs we dont need to manually define the NHTB table as the NHTB mappings can be discovered during Phase 1 negotiations. If we didnt have Junos (or ScreenOS) devices as both ends we would need to manually define the NHTB entries.

We will see this all more clearly in the output when its all working below.

2) ROUTING

a) Define default route to point to the cloud.

set routing-options static route 0.0.0.0/0 next-hop 4.4.4.1

b) Define the next hops for the remote destination networks pointing to the remote st0 IPs

set routing-options static route 192.168.197.0/24 next-hop 20.0.20.3
set routing-options static route 192.168.20.0/24 next-hop 20.0.20.2
set routing-options static route 192.168.30.0/24 next-hop 20.0.20.2
set routing-options static route 192.168.40.0/24 next-hop 20.0.20.2

If this was a point-to-point to point VPN we would add the route for the remote networks pointing to st0.x. But we cant do that with the multipoint config as we only have the one tunnel! So we use the remote tunnel IP for the next hop IP (Remote st0 IP)

3) HUB CONFIG PHASE 1 and 2

a) Define Phase 1 proposal set

set security ike proposal aes-phase1 authentication-method pre-shared-keys
set security ike proposal aes-phase1 dh-group group2
set security ike proposal aes-phase1 authentication-algorithm sha1
set security ike proposal aes-phase1 encryption-algorithm aes-256-cbc
set security ike proposal aes-phase1 lifetime-seconds 86400

b) Define Phase 1 policies

set security ike policy righty2_p1_pol mode main
set security ike policy righty2_p1_pol proposals aes-phase1
set security ike policy righty2_p1_pol pre-shared-key ascii-text testkey2

set security ike policy lefty_p1_pol mode main
set security ike policy lefty_p1_pol proposals aes-phase1
set security ike policy lefty_p1_pol pre-shared-key ascii-text testkey

c) Define Phase 1 gateways

set security ike gateway righty2_gw ike-policy righty2_p1_pol
set security ike gateway righty2_gw address 3.3.3.2
set security ike gateway righty2_gw external-interface fe-0/0/7.0
set security ike gateway righty2_gw version v1-only

set security ike gateway lefty_gw ike-policy lefty_p1_pol
set security ike gateway lefty_gw address 2.2.2.2
set security ike gateway lefty_gw external-interface fe-0/0/7.0
set security ike gateway lefty_gw version v1-only

d) Define Phase 2 proposal set

set security ipsec proposal aes-phase2 protocol esp
set security ipsec proposal aes-phase2 authentication-algorithm hmac-sha1-96
set security ipsec proposal aes-phase2 encryption-algorithm aes-256-cbc
set security ipsec proposal aes-phase2 lifetime-seconds 3600

e) Define Phase 2 policies

set security ipsec policy righty2_p2_pol perfect-forward-secrecy keys group2
set security ipsec policy righty2_p2_pol proposals aes-phase2

set security ipsec policy lefty_p2_pol perfect-forward-secrecy keys group2
set security ipsec policy lefty_p2_pol proposals aes-phase2

f) Define the VPNs

set security ipsec vpn righty2_vpn bind-interface st0.0
set security ipsec vpn righty2_vpn ike gateway righty2_gw
set security ipsec vpn righty2_vpn ike ipsec-policy righty2_p2_pol
set security ipsec vpn righty2_vpn establish-tunnels immediately

set security ipsec vpn lefty_vpn bind-interface st0.0
set security ipsec vpn lefty_vpn ike gateway lefty_gw
set security ipsec vpn lefty_vpn ike ipsec-policy lefty_p2_pol
set security ipsec vpn lefty_vpn establish-tunnels immediately

Note the use of the same tunnel interface.

4) VPN ZONE

Define a VPN security zone and put the tunnel interface in it.

set security zones security-zone vpn interfaces st0.0

5) ADDRESSES

Define any needed addresses for the policy rules

Local address..

set security address-book global address net_192.168.210.0/24 192.168.210.0/24

Remote address..

set security address-book global address net_192.168.197.0/24 192.168.197.0/24
set security address-book global address net_192.168.20.0/24 192.168.20.0/24
set security address-book global address net_192.168.30.0/24 192.168.30.0/24
set security address-book global address net_192.168.40.0/24 192.168.40.0/24

6) POLICY

From the remote networks to the local server network on any port

set security policies from-zone vpn to-zone server-zone policy vpn_core_access match source-address net_192.168.197.0/24
set security policies from-zone vpn to-zone server-zone policy vpn_core_access match source-address net_192.168.20.0/24
set security policies from-zone vpn to-zone server-zone policy vpn_core_access match source-address net_192.168.30.0/24
set security policies from-zone vpn to-zone server-zone policy vpn_core_access match source-address net_192.168.40.0/24
set security policies from-zone vpn to-zone server-zone policy vpn_core_access match destination-address net_192.168.210.0/24
set security policies from-zone vpn to-zone server-zone policy vpn_core_access match application any
set security policies from-zone vpn to-zone server-zone policy vpn_core_access then permit
set security policies from-zone vpn to-zone server-zone policy vpn_core_access then log session-init

From the local server network to the remote networks on any port

set security policies from-zone server-zone to-zone vpn policy vpn_core_access match source-address net_192.168.210.0/24
set security policies from-zone server-zone to-zone vpn policy vpn_core_access match destination-address net_192.168.197.0/24
set security policies from-zone server-zone to-zone vpn policy vpn_core_access match destination-address net_192.168.20.0/24
set security policies from-zone server-zone to-zone vpn policy vpn_core_access match destination-address net_192.168.30.0/24
set security policies from-zone server-zone to-zone vpn policy vpn_core_access match destination-address net_192.168.40.0/24
set security policies from-zone server-zone to-zone vpn policy vpn_core_access match application any
set security policies from-zone server-zone to-zone vpn policy vpn_core_access then permit
set security policies from-zone server-zone to-zone vpn policy vpn_core_access then log session-init

7) ALLOW IKE

Permit IKE on the external facing security zone

set security zones security-zone cloud-link host-inbound-traffic system-services ike

VERIFICATION

SPOKE SIDE VERIFICATION

1) Check Phase 1 is up..

blogger@RIGHTY2> show security ike security-associations
Index   State Initiator cookie Responder cookie Mode           Remote Address
3184912 UP     0b97d84cc0ef6274 6484e2b7dfa56dc0 Main           4.4.4.2

blogger@RIGHTY2> show security ike security-associations detail
IKE peer 4.4.4.2, Index 3184912,
Role: Responder, State: UP
Initiator cookie: 0b97d84cc0ef6274, Responder cookie: 6484e2b7dfa56dc0
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 3.3.3.2:500, Remote: 4.4.4.2:500
Lifetime: Expires in 73786 seconds
Peer ike-id: 4.4.4.2
Xauth assigned IP: 0.0.0.0
Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes256-cbc
   Pseudo random function: hmac-sha1
Traffic statistics:
   Input bytes :                 2872
   Output bytes :                 2244
   Input packets:                   17
   Output packets:                    8
Flags: IKE SA is created
IPSec security associations: 5 created, 4 deleted
Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: 3.3.3.2:500, Remote: 4.4.4.2:500
    Local identity: 3.3.3.2
    Remote identity: 4.4.4.2
    Flags: IKE SA is created

2) Check Phase 2 is up..

blogger@RIGHTY2> show security ipsec security-associations
Total active tunnels: 1
ID    Algorithm       SPI      Life:sec/kb Mon vsys Port Gateway
<131073 ESP:aes-256/sha1 92cde104 2231/ unlim - root 500   4.4.4.2
>131073 ESP:aes-256/sha1 8ef2d2ea 2231/ unlim - root 500   4.4.4.2

blogger@RIGHTY2> show security ipsec security-associations detail
Virtual-system: root
Local Gateway: 3.3.3.2, Remote Gateway: 4.4.4.2
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Version: IKEv1
    DF-bit: clear
    Direction: inbound, SPI: 92cde104, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2200 seconds
    Lifesize Remaining: Unlimited
    Soft lifetime: Expires in 1628 seconds
    Mode: Tunnel, Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 8ef2d2ea, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2200 seconds
    Lifesize Remaining: Unlimited
    Soft lifetime: Expires in 1628 seconds
    Mode: Tunnel, Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

3) Check stats..

blogger@RIGHTY2> show security ipsec statistics
ESP Statistics:
Encrypted bytes:            88160
Decrypted bytes:            48720
Encrypted packets:            580
Decrypted packets:            580
AH Statistics:
Input bytes:                    0
Output bytes:                   0
Input packets:                  0
Output packets:                 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0

HUB SIDE VERIFICATION

1) Check Phase 1 is up..

blogger@VPN-CORE> show security ike security-associations
Index   State Initiator cookie Responder cookie Mode           Remote Address
6340566 UP     3a4e4de2147e1425 3a329010954c4d83 Main           2.2.2.2
6340567 UP     cce17ea8c4fbbaa5 01463a6a9e1bdd7b Main           3.3.3.2

blogger@VPN-CORE> show security ike security-associations detail
IKE peer 2.2.2.2, Index 6340566, Gateway Name: lefty_gw
Role: Initiator, State: UP
Initiator cookie: 3a4e4de2147e1425, Responder cookie: 3a329010954c4d83
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 4.4.4.2:500, Remote: 2.2.2.2:500
Lifetime: Expires in 85593 seconds
Peer ike-id: 2.2.2.2
Xauth assigned IP: 0.0.0.0
Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes256-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group : DH-group-2
Traffic statistics:
   Input bytes :                  916
   Output bytes :                 1000
   Input packets:                    4
   Output packets:                    5
Flags: IKE SA is created
IPSec security associations: 1 created, 0 deleted
Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Initiator, Message ID: 0
    Local: 4.4.4.2:500, Remote: 2.2.2.2:500
    Local identity: 4.4.4.2
    Remote identity: 2.2.2.2
    Flags: IKE SA is created

IKE peer 3.3.3.2, Index 6340567, Gateway Name: righty2_gw
Role: Initiator, State: UP
Initiator cookie: cce17ea8c4fbbaa5, Responder cookie: 01463a6a9e1bdd7b
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 4.4.4.2:500, Remote: 3.3.3.2:500
Lifetime: Expires in 85593 seconds
Peer ike-id: 3.3.3.2
Xauth assigned IP: 0.0.0.0
Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes256-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group : DH-group-2
Traffic statistics:
   Input bytes :                  916
   Output bytes :                 1000
   Input packets:                    4
   Output packets:                    5
Flags: IKE SA is created
IPSec security associations: 1 created, 0 deleted
Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Initiator, Message ID: 0
    Local: 4.4.4.2:500, Remote: 3.3.3.2:500
    Local identity: 4.4.4.2
    Remote identity: 3.3.3.2
    Flags: IKE SA is created

2) Check Phase 2 is up..

blogger@VPN-CORE> show security ipsec security-associations
Total active tunnels: 2
ID    Algorithm       SPI      Life:sec/kb Mon lsys Port Gateway
<131074 ESP:aes-cbc-256/sha1 9434a8a9 2755/ unlim - root 500 2.2.2.2
>131074 ESP:aes-cbc-256/sha1 47c144b2 2755/ unlim - root 500 2.2.2.2
<131073 ESP:aes-cbc-256/sha1 1298cf37 2755/ unlim - root 500 3.3.3.2
>131073 ESP:aes-cbc-256/sha1 12f7c6b5 2755/ unlim - root 500 3.3.3.2

4 phase 2 SAs - one pair for each of the spoke sites - exactly what we expect for a route based VPN.

blogger@VPN-CORE> show security ipsec security-associations detail
ID: 131074 Virtual-system: root, VPN Name: lefty_vpn
Local Gateway: 4.4.4.2, Remote Gateway: 2.2.2.2
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Version: IKEv1
    DF-bit: clear
    Bind-interface: st0.0

Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 600a29
Tunnel Down Reason: SA not initiated
    Direction: inbound, SPI: 9434a8a9, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2752 seconds
    Lifesize Remaining: Unlimited
    Soft lifetime: Expires in 2130 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 47c144b2, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2752 seconds
    Lifesize Remaining: Unlimited
    Soft lifetime: Expires in 2130 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

ID: 131073 Virtual-system: root, VPN Name: righty2_vpn
Local Gateway: 4.4.4.2, Remote Gateway: 3.3.3.2
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Version: IKEv1
    DF-bit: clear
    Bind-interface: st0.0

Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 600a29
Tunnel Down Reason: SA not initiated
    Direction: inbound, SPI: 1298cf37, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2752 seconds
    Lifesize Remaining: Unlimited
    Soft lifetime: Expires in 2118 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 12f7c6b5, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2752 seconds
    Lifesize Remaining: Unlimited
    Soft lifetime: Expires in 2118 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

3) Check NHTB table and routing..

blogger@VPN-CORE> show security ipsec next-hop-tunnels
Next-hop gateway interface   IPSec VPN name                    Flag     IKE-ID                            XAUTH username
20.0.20.2         st0.0       lefty_vpn                         Auto     2.2.2.2
20.0.20.3         st0.0       righty2_vpn                       Auto     3.3.3.2

See how the NHTB entries have been auto installed due to phase 1 negotiations. If we were using a point-to-point VPN we would see no output for this command.
Here is a VPN debug showing the NHTB negotiations between the hub and 2 spokes.

blogger@VPN-CORE> show log VPNLOG | match NHTB
[Jan 2 12:38:42]Construction NHTB payload for local:4.4.4.2, remote:2.2.2.2 IKEv1 P1 SA index 6340566 sa-cfg lefty_vpn
[Jan 2 12:38:42]iked_nhtb_get_tunnel_ifam: got ifa error 0
[Jan 2 12:38:42]Construction NHTB payload for local:4.4.4.2, remote:3.3.3.2 IKEv1 P1 SA index 6340567 sa-cfg righty2_vpn
[Jan 2 12:38:42]iked_nhtb_get_tunnel_ifam: got ifa error 0
[Jan 2 12:38:42]Received NHTB payload from local:4.4.4.2, remote:2.2.2.2 IKEv1 P1 SA index 6340566
[Jan 2 12:38:42]Received NHTB private IP address 20.0.20.2
[Jan 2 12:38:42]In iked_nhtb_config_send_msg Adding GENCFG msg with key = 20002
[Jan 2 12:38:42]iked_nhtb_config_send_msg: Successfully added NHTB Config with key
[Jan 2 12:38:42]nhtb route operation: ifindex=69, (69), rttabl=0
[Jan 2 12:38:42]iked_nhtb_add_entry: Not adding NHTB entry to kernel as IKED_NHTB_IN_KERNEL is set
[Jan 2 12:38:42]Received NHTB payload from local:4.4.4.2, remote:3.3.3.2 IKEv1 P1 SA index 6340567
[Jan 2 12:38:42]Received NHTB private IP address 20.0.20.3
[Jan 2 12:38:43]In iked_nhtb_config_send_msg Adding GENCFG msg with key = 20001
[Jan 2 12:38:43]iked_nhtb_config_send_msg: Successfully added NHTB Config with key
[Jan 2 12:38:43]nhtb route operation: ifindex=69, (69), rttabl=0
[Jan 2 12:38:43]iked_nhtb_add_entry: Not adding NHTB entry to kernel as IKED_NHTB_IN_KERNEL is set

Note how the phase 1 SAs above match the following info..

blogger@VPN-CORE> show security ike security-associations
Index   State Initiator cookie Responder cookie Mode           Remote Address
6340566 UP     3a4e4de2147e1425 3a329010954c4d83 Main           2.2.2.2
6340567 UP     cce17ea8c4fbbaa5 01463a6a9e1bdd7b Main           3.3.3.2

So lets go over the routing from the hub SRX to get to the remote network behind RIGHYT2 - 192.168.197.0/24
Here is how I think it through..

blogger@VPN-CORE> show route 192.168.197.0

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

192.168.197.0/24   *[Static/5] 00:18:43
                    > to 20.0.20.3 via st0.0

The above says to get to the remote network 192.168.197.0/24 go via 20.0.20.3 via st0.0
We know 20.0.20.3 is the IP of st0.0 on RIGHTY2
But how do we get to 20.0.20.3?

blogger@VPN-CORE> show security ipsec next-hop-tunnels
Next-hop gateway interface   IPSec VPN name                    Flag     IKE-ID                            XAUTH username
20.0.20.2         st0.0       lefty_vpn                         Auto     2.2.2.2
20.0.20.3         st0.0       righty2_vpn                       Auto     3.3.3.2

The above says we get to 20.0.20.3 via the righty2_vpn.

4) Check stats..

blogger@VPN-CORE> show security ipsec statistics
ESP Statistics:
Encrypted bytes:            13568
Decrypted bytes:             7420
Encrypted packets:             68
Decrypted packets:             83
AH Statistics:
Input bytes:                    0
Output bytes:                   0
Input packets:                  0
Output packets:                 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0

5) Check ESP is in the session flow table

blogger@VPN-CORE> show security flow session | match esp
In: 2.2.2.2/37940 --> 4.4.4.2/43177;esp, If: fe-0/0/7.0, Pkts: 0, Bytes: 0
In: 2.2.2.2/0 --> 4.4.4.2/0;esp, If: fe-0/0/7.0, Pkts: 0, Bytes: 0
In: 3.3.3.2/4760 --> 4.4.4.2/53047;esp, If: fe-0/0/7.0, Pkts: 0, Bytes: 0
In: 3.3.3.2/0 --> 4.4.4.2/0;esp, If: fe-0/0/7.0, Pkts: 0, Bytes: 0

You can also see the same thing with show security flow session tunnel

SPOKE TO SPOKE COMMUNICATIONS

With what we have set up in this lab, the spokes will not be allowed to talk to each other. If you wanted to allow the spokes to talk to each other you would need..

On the HUB..

An intra vpn zone policy such as..

set security policies from-zone vpn to-zone vpn policy intra-vpn match source-address any
set security policies from-zone vpn to-zone vpn policy intra-vpn match destination-address any
set security policies from-zone vpn to-zone vpn policy intra-vpn match application any
set security policies from-zone vpn to-zone vpn policy intra-vpn then permit
set security policies from-zone vpn to-zone vpn policy intra-vpn then log session-init

On the Spokes..

Adjust the policies accordingly and don't forget to add the routes to the other spoke(s) via st0.0

Model: srx210he
JUNOS Software Release [12.1X45-D15.5]

SRX UTM: Antivirus - Sophos

noreply@blogger.com (junosblogg) — Tue, 26 Nov 2013 10:44:00 +1100

Here is a quick overview of getting Sophos AV working on an SRX

Sophos is the Cloud based solution and so needs an active Internet connection to work. This means the AV database is not stored locally on the SRX like Kaspersky. The SRX uses DNS queries to the Sophos Cloud to perform AV queries. We'll see later how these work.

Sophos can also perform URI content checking over HTTP to detect malware.This is essentially a reputataion check and can be disabled if you wish.

The Sophos solution should put less load on the SRX, processor and memory wise due to not having to download a giant AV database and run checks against it though it does cache responses to improve lookup performance.

1) THE LICENSE

You need the highlighted line..

user@SRX220> show system license
License usage:
                                 Licenses     Licenses    Licenses    Expiry
Feature name                       used    installed      needed
anti_spam_key_sbl                     0            1           0    2014-02-12 11:00:00 EST
idp-sig                               1            1           0    2014-02-12 11:00:00 EST
dynamic-vpn                           0            2           0    permanent
ax411-wlan-ap                         0            2           0    permanent
appid-sig                             0            1           0    2014-02-12 11:00:00 EST
av_key_sophos_engine                  0            1           0    2014-02-12 11:00:00 EST
wf_key_websense_ewf                   1            1           0    2014-02-12 11:00:00 EST

2) PICK THE AV ENGINE

Prior to selecting Sophos AV we can check the AV status..

user@SRX220> show security utm anti-virus status
UTM anti-virus status:

    Anti-virus key expire date: license not installed
    Update server: http://update.juniper-updates.net/AV/SRX220/
           Interval: 60 minutes
           Pattern update status: update disabled due to no license
           Last result: N/A
    Anti-virus signature version: not loaded
    Anti-virus signature compiler version: N/A
    Scan engine type: kaspersky-lab-engine
    Scan engine information: last action result: Engine not ready

Note: by default it shows the Kaspersky engine even though we don't have a license for it and we never configured it .

Trying to update with no AV configured even though we have the Sophos licence..

user@SRX220> request security utm anti-virus sophos-engine pattern-update
Anti-virus update request results: engine type mismatch!

Now we configure Sophos..

user@SRX220# set security utm feature-profile anti-virus type sophos-engine

If we do a commit at this stage and then check the AV status again..

user@SRX220# run show security utm anti-virus status
UTM anti-virus status:

    Anti-virus key expire date: 2014-02-12 11:00:00
    Update server: http://update.juniper-updates.net/SAV/
           Interval: 1440 minutes
           Pattern update status: next update in 1439 minutes
           Last result: new database downloaded
    Anti-virus signature version: 1.02.0 (1.02)
    Scan engine type: sophos-engine
    Scan engine information: last action result: No error

Looks better!

Lets changes the update interval to 12 hours..

user@SRX220# run show security utm anti-virus status

UTM anti-virus status:

    Anti-virus key expire date: 2014-02-12 11:00:00
    Update server: http://update.juniper-updates.net/SAV/
           Interval: 720 minutes
           Pattern update status: next update in 719 minutes
           Last result: already have latest database
    Anti-virus signature version: 1.02.0 (1.02)
    Scan engine type: sophos-engine
    Scan engine information: last action result: No error

Its actually interesting to consider here exactly what the update interval does as we know running Sophos we are not actually downloading the AV signature set.
I believe this is the best description of whats happening with these updates..

Sophos antivirus uses a set of data files that need to be updated on a regular basis. These are not typical virus pattern files; they are a set of small files that help guide virus scanning logic. You can manually download the data files or set up automatic download.
http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/utm-antivirus-sophos-comparison-to-kaspersky.html

3) Bind AV to the UTM Policy

In my case I already have a UTM policy which has Enhanced Web Filtering in it so we will use that.

Here is the UTM policy config before changes..

user@SRX220# run show configuration security utm utm-policy utm_testa
web-filtering {
    http-profile wf_e_profile;

Now we add AV to the UTM policy. You need to define which protocols you want AV to protect with individual profiles. This time we will apply it to all possible choices.

[edit]
user@SRX220# set security utm utm-policy utm_testa anti-virus http-profile junos-sophos-av-defaults

[edit]
user@SRX220# set security utm utm-policy utm_testa anti-virus smtp-profile junos-sophos-av-defaults

[edit]
user@SRX220# set security utm utm-policy utm_testa anti-virus pop3-profile junos-sophos-av-defaults

[edit]
user@SRX220# set security utm utm-policy utm_testa anti-virus imap-profile junos-sophos-av-defaults

[edit]
user@SRX220# set security utm utm-policy utm_testa anti-virus ftp upload-profile junos-sophos-av-defaults

[edit]
user@SRX220# set security utm utm-policy utm_testa anti-virus ftp download-profile junos-sophos-av-defaults

4) OTHER OPTIONS

If you are happy to use the junos-sophos-av-default profile thats it. No more to configure in the AV section.

However when we look at the default profile settings..

user@SRX220# show groups junos-defaults security utm feature-profile anti-virus sophos-engine
pattern-update {
    url http://update.juniper-updates.net/SAV/;
    interval 1440;
}
profile junos-sophos-av-defaults {
    fallback-options {
        default log-and-permit;
        content-size log-and-permit;
        engine-not-ready log-and-permit;
        timeout log-and-permit;
        out-of-resources log-and-permit;
        too-many-requests log-and-permit;
    }
    scan-options {
        uri-check;
        content-size-limit 10000;
        timeout 180;
    }
    notification-options {
        virus-detection {
            type message;
            no-notify-mail-sender;
            custom-message "VIRUS WARNING";
        }
        fallback-block {
            type message;
            no-notify-mail-sender;
        }
    }
}

We dont see any settings for these below sxl-retry and sxl-timeout options so Im not sure what the default settings for them are. SXL is Sophos Extensible List - the servers contain the virus and malware database for scanning operations

user@SRX220# set security utm feature-profile anti-virus sophos-engine ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> pattern-update       Anti-virus sophos-engine pattern update
> profile              Anti-virus sophos-engine profile
sxl-retry            Sxl sophos anti-virus engine query retry (number of times) (0..5)
sxl-timeout          Sxl sophos anti-virus engine timeout (1..5 seconds)

So you may want to set them to whatever you want so you know what those settings are..

user@SRX220# set security utm feature-profile anti-virus sophos-engine sxl-retry ?
Possible completions:
<sxl-retry>          Sxl sophos anti-virus engine query retry (number of times) (0..5)
[edit]
user@SRX220# set security utm feature-profile anti-virus sophos-engine sxl-retry 5

[edit]
user@SRX220# set security utm feature-profile anti-virus sophos-engine sxl-timeout ?
Possible completions:
<sxl-timeout>        Sxl sophos anti-virus engine timeout (1..5 seconds)
[edit]
user@SRX220# set security utm feature-profile anti-virus sophos-engine sxl-timeout 5

5) AV CONFIG

Here is the resulting AV config in full..

user@SRX220> show configuration security utm feature-profile anti-virus
type sophos-engine;
sophos-engine {
    sxl-timeout 5;
    sxl-retry 5;
    pattern-update {
        interval 720;
    }
}

user@SRX220> show configuration security utm utm-policy utm_testa
anti-virus {
    http-profile junos-sophos-av-defaults;
    ftp {
        upload-profile junos-sophos-av-defaults;
        download-profile junos-sophos-av-defaults;
    }
    smtp-profile junos-sophos-av-defaults;
    pop3-profile junos-sophos-av-defaults;
    imap-profile junos-sophos-av-defaults;
}
web-filtering {
    http-profile wf_e_profile;
}

To make it work you attach the UTM policy to the policy you want to enforce AV checking and note that policy will also do web filtering.

Finally I have setup the same syslog files as from the Kaspersky blog (AV_OPS and AV_VIRUS)

To see the config for the syslog setup and the enforcing policy please check the Kaspersky lab blog - they are exactly the same.

6) TESTING

All test results are the same as per the Kaspersky blog so I wont bore you by repeating them here.

We'll just quickly verify its stats..

user@SRX220> show security utm anti-virus statistics
UTM Anti Virus statistics:
MIME-whitelist passed:                0
URL-whitelist passed:                 0
Scan Request:

Total           Clean         Threat-found    Fallback
      24              21              3               0

Fallback:
                              Log-and-Permit    Block             Permit
Engine not ready:                0                 0                 0
Out of resources:                0                 0                 0
Timeout:                         0                 0                 0
Maximum content size:            0                 0                 0
Too many requests:               0                 0                 0
Others:                          0                 0                 0

For something a little different lets dig a bit deeper into its workings..

AV Traceoptions..

To do traceoptions for AV it doesnt appear you can set the traceoptions file under either security > utm > feature-profile > anti-virus or even under security > utm. You have to set the file directly under security for this type of traceoptions though that isn't necessarily the case for all the hierarchies under security.

Here is the full AV traceoptions settings I used based on..
http://kb.juniper.net/InfoCenter/index?page=content&id=KB21781&smlogin=true#UTMAntiVirus

user@SRX220# run show configuration | match traceoptions | display set
set security utm traceoptions flag all
set security utm application-proxy traceoptions flag all
set security utm feature-profile anti-virus traceoptions flag all
set security traceoptions file SEC-UTM
set security traceoptions file size 1m
set security traceoptions file files 3
set security traceoptions file world-readable
set security traceoptions flag all

Be aware of the phenominal amount of data these traceoptions generate. The caveats in the above link are important...

Below are some selected output from the traceoptions that are understandable/meaningful.
Naturally with traceoptions you get way more than you need so you need to know what to look for. Surely only a Junos programmer could undestand all of the output!

Looks like the event of trying to download the eicar file is assigned a unique app_obj which you can follow through the log entries to see whats happening with said event.

Starting the download..
Nov 21 13:46:26 13:46:26.386915:CID-0:RT:HTTP: 10.222.222.10(54767)->188.40.238.250(80) server header /download/eicar_com.zip is received.

app_obj assigned..
Nov 21 13:46:26 13:46:26.386915:CID-0:RT:: HTTP http_post_event_handler 245 app_obj 0x4ac767b8 event_id 11.

Checks if it is in the whitelist..
Nov 21 13:46:26 13:46:26.386915:CID-0:RT:check url whitelist: (0) url:www.eicar.org/download/eicar_com.zip

Not in whitelist..
Nov 21 13:46:26 13:46:26.386915:CID-0:RT:not found

We need to scan it..
Nov 21 13:46:26 13:46:26.386915:CID-0:RT:SAV: sav_is_scan_required 720 app_obj 0x4ac767b8 sav_ctx 0x4ac76650

Nov 21 13:46:26 13:46:26.386915:CID-0:RT:SAV: check_sav_configuration 584 app_obj 0x4ac767b8 sav_info 0x4db94bf0 filename www.eicar.org/download/eicar_com.zip.

Size confirms its our file..
Nov 21 13:46:26 13:46:26.386915:CID-0:RT:AV: current content size:184, config maximum content size:10000K

Nov 21 13:46:26 13:46:26.386915:CID-0:RT:check_sav_configuration: need scan

We send the scan request to the cloud..
Nov 21 13:46:26 13:46:26.386915:CID-0:RT:SAV: sav_send_sxl_request 814 app_obj 0x4ac767b8 sav_ctx 0x4ac76650 send dns to a3d093b len 142 (0)

Nov 21 13:46:26 13:46:26.390513:CID-0:RT:: APPPXY HANDLER EVENT utm_apppxy_event_scheduler 234 app_obj 0x4ac767b8 event_handler=222e50b4.

Nov 21 13:46:26 13:46:26.390513:CID-0:RT:Release APPPXY:0x4E44B050 app object 0x4ac767b8 for flow 10.222.222.10(54767)->188.40.238.250(80).

Response back from the cloud..
Nov 21 13:46:26 13:46:26.705882:CID-0:RT:SAV: sav_sxl_response_callback 1918 context 0x4ac75010 request 0x4e44be20 app_obj 0x4ac767b8 rtn 11

Nov 21 13:46:26 13:46:26.705882:CID-0:RT:APPPXY: HTTP on_http_mod_sav_recv_scan_result 563 app_obj 0x4ac767b8 http_session 0x4ac76a28

Nov 21 13:46:26 13:46:26.705882:CID-0:RT:APPPXY: HTTP http_sav_process_scan_result 899 app_obj 0x4ac767b8 http_session 0x4ac76a28 flow_orig 1

We drop the request..
Nov 21 13:46:26 13:46:26.705882:CID-0:RT: drop_pak_queue 658 q AV-CTX(0x4ac766f0) total 2 bytes 400

The drop message is sent to the browser..
Nov 21 13:46:26 13:46:26.705882:CID-0:RT:APPPXY: HTTP http_create_drop_msg 222 protocol_only 0, plain_msg 0

I cant be certain all my descriptions of the log events are correct but it makes sense in light of what we know how it works and what happened. Comments welcome..

Here is the corresponding log entry to the above event..

user@SRX220> show log AV_VIRUS
Nov 21 13:46:26 SRX RT_UTM: AV_VIRUS_DETECTED_MT: AntiVirus: Virus detected: from 188.40.238.250:80 to 10.222.222.10:54767 source-zone untrust www.eicar.org/download/eicar_com.zip file www.eicar.org/download/eicar_com.zip virus EICAR-AV-Test URL:HTTP://SXL2-01.P.LINK.SOPHOS.COM/T/en/EICAR-AV-Test username N/A roles N/A

Model: srx220h
JUNOS Software Release [12.1X44-D25.5]