I recently installed an SRX in NZ so I though I'd put up here the working ADSL config for our cousins across the pond...
Telecom NZ - PPPOA
at-1/0/0 {
mtu 1540;
encapsulation atm-pvc;
atm-options {
vpi 0;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation atm-ppp-vc-mux;
vci 0.100;
ppp-options {
pap {
default-password "!9$uQQhy76fg543es8XYoZGq.P5QF9A"; ## SECRET-DATA
local-name "whoareu.xadsl@xtra.co.nz";
local-password "%9$q.Qnkn8765sgvq8LVbs24aDi"; ## SECRET-DATA
passive;
}
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop at-1/0/0.0;
SRX GLOBAL ADDRESS BOOK
Lets have a look today at the issue of using the WebUI with the Global address book.
When I say Global address book, I mean using creating addresses on the SRX in this way...
root# set security address-book ?
Possible completions:
<book-name> Address book name
global Default global address book name
Example of address with the Global Address book..
security {
address-book {
global {
address aaaa 1.1.1.1/32;
address bbbb 2.2.2.2/32;
}
}
These Global addresses form a common address pool that should be available for use in any zone as opposed to the old way of creating separate address books under each zone.
When I say Global address book, I mean using creating addresses on the SRX in this way...
root# set security address-book ?
Possible completions:
<book-name> Address book name
global Default global address book name
Example of address with the Global Address book..
security {
address-book {
global {
address aaaa 1.1.1.1/32;
address bbbb 2.2.2.2/32;
}
}
These Global addresses form a common address pool that should be available for use in any zone as opposed to the old way of creating separate address books under each zone.
JUNOS ANNOTATE
A great way to add your own comments to any part of a Junos config.
Let say we have this DHCP config...
services {
ssh;
telnet;
xnm-clear-text;
web-management {
http {
interface vlan.7;
}
https {
system-generated-certificate;
interface vlan.7;
}
}
dhcp {
pool 10.1.1.0/24 {
address-range low 10.1.1.101 high 10.1.1.254;
default-lease-time 86400;
domain-name company.com;
router {
10.1.1.1;
}
}
And we wish to place some kind of comment on the DHCP pool as there is no description statement associated with DHCP.
Let say we have this DHCP config...
services {
ssh;
telnet;
xnm-clear-text;
web-management {
http {
interface vlan.7;
}
https {
system-generated-certificate;
interface vlan.7;
}
}
dhcp {
pool 10.1.1.0/24 {
address-range low 10.1.1.101 high 10.1.1.254;
default-lease-time 86400;
domain-name company.com;
router {
10.1.1.1;
}
}
And we wish to place some kind of comment on the DHCP pool as there is no description statement associated with DHCP.
SRX ADSL
Here is a couple of SRX ADSL configs to 2 different ISPs.
Both these configs have been tested to actually work.
1) Telstra - PPPOA
at-1/0/0 {
mtu 1540;
encapsulation atm-pvc;
atm-options {
vpi 8;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation atm-ppp-vc-mux;
vci 8.35;
ppp-options {
chap {
default-chap-secret "$9$78fgoJGD.fT3JtuBIcS"; ## SECRET-DATA
local-name "yourname@direct.telstra.net";
passive;
}
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop at-1/0/0.0
2) Netspace - PPPOE
at-1/0/0 {
mtu 1492;
encapsulation ethernet-over-atm;
atm-options {
vpi 8;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation ppp-over-ether-over-atm-llc;
vci 8.35;
}
}
pp0 {
unit 0 {
point-to-point;
ppp-options {
pap {
default-password "$9$CYEtAOwKvLXNdpqvLx92g5Qz"; ## SECRET-DATA
local-name "yourname@netspace.net.au";
local-password "$9$vMwMxdoraUDHq7XaUjhTQRhc"; ## SECRET-DATA
passive;
}
}
pppoe-options {
underlying-interface at-1/0/0.0;
idle-timeout 0;
auto-reconnect 2;
client;
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop pp0.0
Both these configs have been tested to actually work.
1) Telstra - PPPOA
at-1/0/0 {
mtu 1540;
encapsulation atm-pvc;
atm-options {
vpi 8;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation atm-ppp-vc-mux;
vci 8.35;
ppp-options {
chap {
default-chap-secret "$9$78fgoJGD.fT3JtuBIcS"; ## SECRET-DATA
local-name "yourname@direct.telstra.net";
passive;
}
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop at-1/0/0.0
2) Netspace - PPPOE
at-1/0/0 {
mtu 1492;
encapsulation ethernet-over-atm;
atm-options {
vpi 8;
}
dsl-options {
operating-mode auto;
}
unit 0 {
encapsulation ppp-over-ether-over-atm-llc;
vci 8.35;
}
}
pp0 {
unit 0 {
point-to-point;
ppp-options {
pap {
default-password "$9$CYEtAOwKvLXNdpqvLx92g5Qz"; ## SECRET-DATA
local-name "yourname@netspace.net.au";
local-password "$9$vMwMxdoraUDHq7XaUjhTQRhc"; ## SECRET-DATA
passive;
}
}
pppoe-options {
underlying-interface at-1/0/0.0;
idle-timeout 0;
auto-reconnect 2;
client;
}
family inet {
negotiate-address;
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop pp0.0
SRX UTM: Web Filtering (Enhanced Web Filtering)
This summary is not available. Please
click here to view the post.
SRX UTM: Web Filtering (Local)
Time to test the UTM Web Filtering feature.
The first thing to know is that there are 4 different ways to do this on the SRX.
1) Surfcontrol - This is know as Integrated Web Filtering and uses a cloud based Surfcontrol server to categorise URLs. This option requires a license and of course you can test with the 30 day trial license. The cloud based Surfcontrol server doesn't permit or deny anything. When queried by the SRX it provides a category that is permitted or denied by the policy you create on the SRX. The URL-to-category site results from the Surfcontrol server are cached locally which means subsequent requests for the same site don't require a lookup on the Surfcontrol server. This is a sensible approach as it means you dont have to download the whole database from Surfcontrol every time you start the SRX - it just requests the info from Surfcontrol on as as needed realtime basis.
Note: Surfcontrol is now owned by Websense though Juniper still name this option as Surfcontrol.
2) Enhanced Web Filtering - This is another type of Integrated solution which uses the Websense ThreatSeeker Cloud (TSC). Similar to Surfcontrol option above it provides a cattergory for the site to be checked but in addition also provides a reputation for the site.
A license is required for this option.
Juniper consider this option "next-generation URL filtering solution, building upon the existing SurfControl solution".
3) Websense - This is known Redirect Web Filtering and uses your local Websense server. This option does not require a licence. The main difference here to the Surfcontrol option is the the Websense server itself, through its own polices is doing the denying or permitting.
4) Local lists. This option uses local black and white lists to permit or deny access to URLs. No license required.
In this post I will configure and test the Local lists
The first thing to know is that there are 4 different ways to do this on the SRX.
1) Surfcontrol - This is know as Integrated Web Filtering and uses a cloud based Surfcontrol server to categorise URLs. This option requires a license and of course you can test with the 30 day trial license. The cloud based Surfcontrol server doesn't permit or deny anything. When queried by the SRX it provides a category that is permitted or denied by the policy you create on the SRX. The URL-to-category site results from the Surfcontrol server are cached locally which means subsequent requests for the same site don't require a lookup on the Surfcontrol server. This is a sensible approach as it means you dont have to download the whole database from Surfcontrol every time you start the SRX - it just requests the info from Surfcontrol on as as needed realtime basis.
Note: Surfcontrol is now owned by Websense though Juniper still name this option as Surfcontrol.
2) Enhanced Web Filtering - This is another type of Integrated solution which uses the Websense ThreatSeeker Cloud (TSC). Similar to Surfcontrol option above it provides a cattergory for the site to be checked but in addition also provides a reputation for the site.
A license is required for this option.
Juniper consider this option "next-generation URL filtering solution, building upon the existing SurfControl solution".
3) Websense - This is known Redirect Web Filtering and uses your local Websense server. This option does not require a licence. The main difference here to the Surfcontrol option is the the Websense server itself, through its own polices is doing the denying or permitting.
4) Local lists. This option uses local black and white lists to permit or deny access to URLs. No license required.
In this post I will configure and test the Local lists
SRX IDP
This post will show you how to get IDP on an SRX100H going and tested
to be working.
I will be using a Trial licence which is valid for 30days.
1) GET AND INSTALL THE IDP LICENSE
a) First make sure you can ping a URL from your SRX
as the download process will use name lookups.
blogger@LEFTY> ping www.juniper.net inet
PING e1824.dscb.akamaiedge.net (184.87.23.148): 56 data bytes
64 bytes from 184.87.23.148: icmp_seq=0 ttl=54 time=33.373 ms
64 bytes from 184.87.23.148: icmp_seq=1 ttl=54 time=30.299 ms
64 bytes from 184.87.23.148: icmp_seq=2 ttl=54 time=29.531 ms
^C
--- e1824.dscb.akamaiedge.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.531/31.068/33.373/1.660 ms
If that doesn’t work, setup name servers in the config.
Subscribe to:
Posts (Atom)