Hi,
As of now, the licensing has not been implemented. So essentially you will be getting all the features on the box.
Regards,
Sahil Sharma
---------------------------------------------------
Please mark my solution as accepted if it helped, Kudos are appreciated as well.
Hi!
I need some help figuring out the best configuration scenario for my network. Please have a look at the attached image as I’ll refer to it.
I have a two ISP setup with BGP to both peers. My SRX Router cluster both are connected to each ISP. Right after the routers I’ve placed my firewalls. As you can see on the pic each router is connected to only one firewall through the ‘reth2’ interface. This is only one physical interface.
And after the firewalls the core switch and the rest of the equipment is located.
So, my problem is the redundancy between the router and the firewall cluster. From the beginning I used Interface Monitor to trigger the failover in case of a breakdown. But this solution was either misconfigured by me or did not solve it the way I wanted. During a reboot of both the primary nodes in each cluster it all got stuck in a loop arguing witch node should be primary/secondary. Interfaces going wild, and so on.
Now I only have a weight difference on the redundancy groups on each node but I realize that if node0 on the router side should fail, node0 in the firewall cluster will still try to use this patch since it does not care about interface status.
What’s my best option here? Should I put a switch in between the two clusters? Connecting all reth2 interfaces to one switch? Or can I trim the configuration to work with my topology?
All feedback appreciated!
Hi,
You are required to buy either a JSB, JSE or JSB-L license when buying a SRX300 series firewall.
JSB: Firewall, routing, NAT, VPN and Junos "basics" (automation etc.) and MPLS
JSE: JSB + Application Security as a perpetual license
JSB-L: JSB but limited to 200 Mbps throughput and 40 Mbps IPsec/NGFW
On top you can then buy subscription licenses for NGFW features (and these will include application security so not much need for JSE).
For now the JSB/JSE/JSB-L features are not enforced but should be during 2017. Subscription licenses are enforced.
MPLS was originally only in JSE but was moved to JSB some time in Q3 2016.
I hope this answers your question.
I've found that the screen settings are a much better solution to fighting issues like syn attacks than firewall filters because of the nature of these attacks. The issue with filters is the changing nature of the packets and sources. These do work well if you have specific combinations of protocol, port and destination address that can easily be dropped. Or if there is some other reliable pattern to match on. But the heuristic basis of the screens typically work better in my opinion on syn attacks.
But the best solutions are DDoS specific offramp scrubbing products like Arbor Networks.
I think the real feature you want is a icense to Logical systems (only on SRX) that create a logical SRX inside the chassis that can easily be sub-managed by a user account.
With your current setup, the situation is slightly more complicated. You would need to create a customer user class and then restrict that class to the routing-instance hierarchy as desired.
http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/configuration/access-login-class.html
An extra note regarding logical systems on SRX. This is only supported by highend SRX platforms (SRX1400/3400/3600/5000 series) -not branch (srx100/200/300/550/650) series and SRX4100/4200.
From what I see, logical systems on SRX will not be a good longterm solution as virtualisation of the SRX is solved with vSRX instead of logical systems in large physical devices.
Hi Folks,
To add.. there are differences between instance type virtual-router and Logical System deployments.
With Logical System configuration the box will spin individual rpd daemon for every LS uniquely. Which is not the case with addition of routing-instance with type virtual-router in the box.
Few interesting content on logical-systems
https://www.juniper.net/documentation/en_US/junos12.1x46/topics/concept/logical-systems-overview.html
https://www.juniper.net/documentation/en_US/junos12.1x44/information-products/pathway-pages/security/security-logical-system-index.html
-A.Rengaramalingam
Is there any way to obtain a log when I lose Internet conectivity from one of my two ISPs?
I was thinking in something similar to rpm services: when SRX send ICMP packets to an Internet host and this host does not respond, automatically generate a log that I can send to a syslog server. Is it possible something like that?
Hello,
You can explore the IP Monitoring feature on SRX devices.
Regards,
Rushi
I read that some of the larger SRX units support CGNAT, do the smaller ones support it as well?
Also, do all SRX units support MPLS?
Below is teh config for traceoption:-
show configuration | match traceoption | display set
set security flow traceoptions file 001_check
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter trace-filer source-prefix x.x.x.x/32
set security flow traceoptions packet-filter trace-filer destination-prefix y.y.y.y/32
Below shows session is forming
show security flow session destination-prefix y.y.y.y source-prefix x.x.x.x
node0:
------------------------------
Flow Sessions on FPC1 PIC0:
Session ID: 20063422, Policy name: POL-KCC-ORN-001/37, State: Active, Timeout: 2, Valid
In: x.x.x.x/2 --> y.y.y.y/14560;icmp, If: reth0.2269, Pkts: 1, Bytes: 84
Out: y.y.y.y/14560 --> x.x.x.x/2;icmp, If: reth1.452, Pkts: 1, Bytes: 84
Session ID: 20340282, Policy name: POL-KCC-ORN-001/37, State: Active, Timeout: 4, Valid
But in traceoptions only get the dropped packet
13:59:55.445631:CID-01:FPC-01:
Dec 9 13:59:56 13:59:55.445660:CID-01:FPC-01:
Dec 9 13:59:56 13:59:55.445682:CID-01:FPC-01:
Dec 9 13:59:56 13:59:55.445691:CID-01:FPC-01:
Dec 9 13:59:56
Good morning (o;
First of all...I'm pretty new to SRX devices....
I've setup a site-to-site policy-based VPN with the help of the online configuration tool, and from what I can tell the VPN is up and passed phase 1 and 2:
root> show security ipsec security-associations
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<2 ESP:aes-cbc-128/sha1 9ad983c5 2287/ unlim - root 500 X.X.53.70
>2 ESP:aes-cbc-128/sha1 10c464e3 2287/ unlim - root 500 X.X.53.70
<2 ESP:3des/sha1 b768d72 2288/ unlim - root 500 X.X.53.70
>2 ESP:3des/sha1 d470e603 2288/ unlim - root 500 X.X.53.70
But somehow the policies don't work correctly as I can't establish any traffic between the 10/16 and 192.168.178/24 subnets.
Trying to access a website on the remote end I see this flow session entry:
Session ID: 2580, Policy name: vpnpolicy-trust-untrust-lengnau/5, Timeout: 8, Valid
In: 10.0.100.2/49184 --> 192.168.178.20/80;tcp, If: ge-0/0/1.0, Pkts: 3, Bytes: 180
Out: 192.168.178.20/80 --> Y.Y.90.159/21771;tcp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0
How do I interpret this two lines correctly?
First line makes sense to me, and 3 packets are sent...but the second line doesn't make any sense to me...
Hello,
Second line indicates that Source IP 10.0.100.2 port 49184 is NATed to Y.Y.90.159 port 21771.
Since it is a policy based VPN, I assume that you do not intend to NAT the traffic & due to some configuration, it is getting NATed.
Can you show the Source NAT configuration present in your configuration?
Regards,
Rushi
look its a open world
i will not die if i dont get help
but if one wants to help then help and if not then don't help
i have been using my junper router for 4 years and i am more familiar with the editor and not the CLI
i am not going to go some study rampage because i need to get DHCP to work via editor and getting half help
life is not that dificult man, this is open internet there will always be people who will go that extra length to help, some will not help at all
What i need help with? I posted everything what my current config is and just need what the config should be. If no one will help me with that wihtout going to buy no book then so be it
Thanks for your input
P.S. I did not say am not grateful, but if i mention million times i need editor not CLI and someone keep posting stuff that can mess up my whole config then am not with that
Hi Friends,
i'm facing a strange issue in lab, bascially my setup is like below:
The requirement is on EX4550, ping between the vlan.30(default routing-instance) and vlan.80 (belongs to routing-instance 80), the traffic has to flow through two SRX, transit through different zone/ routing-instance on both, this is done.
However, what I can't figure out is why on EX4550 vlan.30, it's unable to ping the self ip of SRX 240D vlan 80 (8.8.80.230) and also from EX4550 vlan 80 to SRX240U vlan 30 self ip.
But if i just reverse, initiate the ping from either SRX240 (vlan 80) to EX4550 (vlan30), then it works, same for SRX (vlan30) to EX4550 (vlan80)
Hence, it seems traffic from EX4550 has reached to SRX240 but SRX240 didn't reply back.
Directly ping from EX4550 vlan 80 to SRX 240D vlan 80 same subnet is working.
Relevant config for SRX240D:
demo@SRX240D# show interfaces vlan
unit 30 {
family inet {
address 8.8.30.231/24;
}
}
unit 100 {
family inet {
filter {
input FROM_GL_TO_30;
}
address 8.8.100.231/24;
}
demo@SRX240D# show security zones
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
vlan.0;
vlan.3;
vlan.100;
}
}
security-zone TR_R30 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
vlan.30;
}
}
demo@SRX240D# show routing-instances
30 {
instance-type virtual-router;
interface vlan.30;
routing-options {
static {
route 8.8.80.0/24 next-table inet.0;
}
}
}
demo@SRX240D# show firewall
family inet {
filter FROM_GL_TO_30 {
term 1 {
from {
destination-address {
8.8.30.0/24;
}
}
then {
count RINSTANCE;
routing-instance 30;
}
}
term 2 {
then accept;
}
}
}
demo@SRX240D# show interfaces ge-0/0/8
description to_SRX240UGE8;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members vlan100;
}
}
}
SRX240U
demo@SRX240U# show interfaces ge-0/0/8
description To_SRX240D_GE8;
vlan-tagging;
unit 100 {
vlan-id 100;
family inet {
filter {
input FROM_GL_TO_80;
}
address 8.8.100.230/24;
}
}
demo@SRX240U# show firewall
family inet {
filter FROM_GL_TO_80 {
term 1 {
from {
destination-address {
8.8.80.0/24;
}
}
then {
count RINSTANCE;
routing-instance 80;
}
}
term 2 {
then accept;
}
}
}
demo@SRX240U# show routing-instances
80 {
instance-type virtual-router;
interface vlan.80;
routing-options {
static {
route 8.8.30.0/24 next-table inet.0;
}
}
}
demo@SRX240U# show security policies
from-zone TR_R80 to-zone trust {
policy R80_to_TR {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
count;
}
}
}
from-zone trust to-zone TR_R80 {
policy TR_to_R80 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
count;
}
}
}
default-policy {
permit-all;
}
demo@SRX240U# show security zones
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
vlan.0;
vlan.3;
ge-0/0/8.100;
}
application-tracking;
}
security-zone TR_R80 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
vlan.80;
}
}
some output when I inititate the ping from EX4550 to differet vlan on SRX.
demo@EX4550# run ping 8.8.30.231
PING 8.8.30.231 (8.8.30.231): 56 data bytes
64 bytes from 8.8.30.231: icmp_seq=0 ttl=64 time=3.508 ms
64 bytes from 8.8.30.231: icmp_seq=1 ttl=64 time=3.003 ms
demo@EX4550# run ping 8.8.30.231 routing-instance 80 PING 8.8.30.231 (8.8.30.231): 56 data bytes
demo@EX4550# run show route
80.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
8.8.30.0/24 *[Static/5] 01:05:41
> to 8.8.80.230 via vlan.80
on first SRXU which is the gateway
demo@SRX240U> show security flow session protocol icmp
Session ID: 69169, Policy name: R80_to_TR/7, Timeout: 56, Valid
In: 8.8.80.232/0 --> 8.8.30.231/24586;icmp, If: vlan.80, Pkts: 1, Bytes: 84
Out: 8.8.30.231/24586 --> 8.8.80.232/0;icmp, If: ge-0/0/8.100, Pkts: 0, Bytes: 0
Session ID: 69170, Policy name: R80_to_TR/7, Timeout: 58, Valid
In: 8.8.80.232/1 --> 8.8.30.231/24586;icmp, If: vlan.80, Pkts: 1, Bytes: 84
Out: 8.8.30.231/24586 --> 8.8.80.232/1;icmp, If: ge-0/0/8.100, Pkts: 0, Bytes: 0
Session ID: 69171, Policy name: R80_to_TR/7, Timeout: 58, Valid
In: 8.8.80.232/2 --> 8.8.30.231/24586;icmp, If: vlan.80, Pkts: 1, Bytes: 84
Out: 8.8.30.231/24586 --> 8.8.80.232/2;icmp, If: ge-0/0/8.100, Pkts: 0, Bytes: 0
It should reach to the second SRXD as Firewall filter counter is incrementing.
demo@SRX240D> show security flow session protocol icmp
Session ID: 210721, Policy name: TR_to_R30/6, Timeout: 26, Valid
In: 8.8.80.232/41 --> 8.8.30.231/24586;icmp, If: vlan.100, Pkts: 1, Bytes: 84
Out: 8.8.30.231/24586 --> 8.8.80.232/41;icmp, If: .local..5, Pkts: 0, Bytes: 0
Session ID: 210757, Policy name: TR_to_R30/6, Timeout: 2, Valid
In: 8.8.80.232/18 --> 8.8.30.231/24586;icmp, If: vlan.100, Pkts: 1, Bytes: 84
Out: 8.8.30.231/24586 --> 8.8.80.232/18;icmp, If: .local..5, Pkts: 0, Bytes: 0
Session ID: 210762, Policy name: TR_to_R30/6, Timeout: 4, Valid
In: 8.8.80.232/20 --> 8.8.30.231/24586;icmp, If: vlan.100, Pkts: 1, Bytes: 84
Out: 8.8.30.231/24586 --> 8.8.80.232/20;icmp, If: .local..5, Pkts: 0, Bytes: 0
I've enable a tranoption for flow on SRX240D, but I didn;t find anything obvious.
Please advise which part i miss? Many thanks.
Hi,
Please assist me with the above issue.
Do you have "security datapath-debug" is configured and active in this box?
Bumping up one more time before I contact JTAC....
Thank you so much , i checked a little for our network characteristic
we have thousands of syn packet every second 
is there a way to limit a range the syn mtu between 1000-1800 on mx ?
[root@localhost islemler]# tcpdump -nn 'tcp[13] & 2 == 2' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes 22:10:06.979208 IP 64.233.188.26.25 > 213.238.166.79.39446: Flags [S.], seq 1442487946, ack 2772870502, win 42408, options [mss 1380,sackOK,TS val 736021397 ecr 821225169,nop,wscale 7], length 0 22:10:06.980218 IP 37.123.101.131.80 > 85.132.117.206.3836: Flags [S.], seq 1450946354, ack 3634974204, win 14480, options [mss 1460,sackOK,TS val 3217225880 ecr 9187416,nop,wscale 7], length 0 22:10:06.982865 IP 208.67.1.11.443 > 213.238.172.239.54960: Flags [S.], seq 3742838734, ack 3491591898, win 11680, options [mss 1460], length 0 22:10:06.984078 IP 93.174.93.103.48946 > 213.238.171.197.80: Flags [S], seq 1014144747, win 29200, options [mss 1460,sackOK,TS val 213226102 ecr 0,nop,wscale 7], length 0 22:10:06.986077 IP 93.174.93.103.41036 > 185.9.157.196.80: Flags [S], seq 963414185, win 29200, options [mss 1460,sackOK,TS val 213226108 ecr 0,nop,wscale 7], length 0 22:10:06.989228 IP 173.194.220.26.25 > 213.238.166.76.56603: Flags [S.], seq 3005784396, ack 1821054237, win 42540, options [mss 1430,sackOK,TS val 1717880936 ecr 821225711,nop,wscale 7], length 0 22:10:06.992168 IP 80.236.217.43.62346 > 37.123.99.13.80: Flags [S], seq 2892144143, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0 22:10:06.992426 IP 37.123.99.13.80 > 80.236.217.43.62346: Flags [S.], seq 1778744980, ack 2892144144, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 22:10:06.992848 IP 185.118.142.80.31739 > 198.31.186.19.22: Flags [S], seq 3946997301, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 498299067 ecr 0], length 0 22:10:06.992943 IP 185.118.142.80.31724 > 198.31.186.5.22: Flags [S], seq 3331660361, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 498299067 ecr 0], length 0 22:10:06.993801 IP 185.118.142.80.31752 > 198.31.186.32.22: Flags [S], seq 1758905277, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 498299068 ecr 0], length 0 22:10:06.993852 IP 185.118.142.80.31748 > 198.31.186.28.22: Flags [S], seq 745465698, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 498299068 ecr 0], length 0 22:10:06.995477 IP 45.55.135.10.42458 > 185.9.156.251.80: Flags [S], seq 3081786914, win 29200, options [mss 1460,sackOK,TS val 1751774 ecr 0,nop,wscale 6], length 0 22:10:06.996231 IP 95.82.131.230.2874 > 37.123.99.13.80: Flags [S], seq 2751335161, win 8192, options [mss 1460,nop,nop,sackOK], length 0 22:10:06.998894 IP 185.118.143.226.62763 > 5.196.7.246.80: Flags [S], seq 2274759170, win 8192, options [mss 1460,nop,nop,sackOK], length 0 22:10:07.001371 IP 173.194.220.27.25 > 213.238.166.79.35239: Flags [S.], seq 3732730745, ack 1833826239, win 42540, options [mss 1430,sackOK,TS val 1731389821 ecr 821225721,nop,wscale 7], length 0 22:10:07.002380 IP 85.158.137.99.25 > 213.238.166.76.53871: Flags [S.], seq 4208165307, ack 1452091138, win 4380, options [mss 1460,nop,nop,TS val 1278707629 ecr 821225751,sackOK,eol], length 0 22:10:07.003715 IP 185.171.88.66.58459 > 37.6.1.117.6881: Flags [S], seq 985513053, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.004321 IP 185.90.81.137.3128 > 58.218.200.148.46285: Flags [S.], seq 1433709853, ack 3574231009, win 14480, options [mss 1460,sackOK,TS val 1857791237 ecr 99247027,nop,wscale 6], length 0 22:10:07.005853 IP 46.150.5.130.3389 > 185.118.142.10.53347: Flags [S.], seq 2801548885, ack 2525067564, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.013722 IP 162.158.210.105.30444 > 185.9.156.148.80: Flags [S], seq 823114944, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 10], length 0 22:10:07.013741 IP 46.150.103.116.3389 > 185.118.142.10.53354: Flags [S.], seq 3124588752, ack 1775530236, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.013919 IP 185.9.156.148.80 > 162.158.210.105.30444: Flags [S.], seq 895421771, ack 823114945, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 22:10:07.019195 IP 46.150.105.244.3389 > 185.118.142.10.53357: Flags [S.], seq 1242415396, ack 3616802501, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.020248 IP 46.150.108.29.3389 > 185.118.142.10.53359: Flags [S.], seq 1964264096, ack 681840602, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.023682 IP 186.183.143.156.29955 > 37.123.103.57.23: Flags [S], seq 3510829056, win 14600, options [mss 1460], length 0 22:10:07.025356 IP 46.150.108.254.3389 > 185.118.142.10.53360: Flags [S.], seq 2797634464, ack 1200156262, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.026445 IP 185.118.142.55.11290 > 167.89.200.179.22: Flags [S], seq 3221492566, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 385814529 ecr 0], length 0 22:10:07.026680 IP 185.118.142.55.11424 > 167.89.201.22.22: Flags [S], seq 47552746, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 385814530 ecr 0], length 0 22:10:07.028392 IP 37.123.99.165.80 > 78.182.80.113.38555: Flags [S.], seq 2186475341, ack 2667760937, win 14480, options [mss 1460,sackOK,TS val 387004685 ecr 2317883,nop,wscale 7], length 0 22:10:07.028651 IP 208.180.40.132.25 > 178.20.226.22.56603: Flags [S.], seq 2820323684, ack 2784469514, win 4380, options [mss 1460,nop,nop,TS val 1278669143 ecr 2167564213,sackOK,eol], length 0 22:10:07.029671 IP 46.151.84.75.3389 > 185.118.142.10.53364: Flags [S.], seq 3567298315, ack 1895424507, win 64000, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0 22:10:07.030077 IP 37.123.99.13.80 > 193.125.52.175.52182: Flags [S.], seq 645193683, ack 3767641660, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 22:10:07.031082 IP 66.249.93.91.62170 > 37.123.101.131.80: Flags [S], seq 3945429612, win 42780, options [mss 1380,sackOK,TS val 667426434 ecr 0,nop,wscale 7], length 0 22:10:07.032151 IP 122.200.228.232.25 > 213.238.172.130.2244: Flags [S.], seq 4219821937, ack 2790407854, win 65535, options [mss 1460,sackOK,eol], length 0 22:10:07.040290 IP 89.248.167.173.6275 > 37.123.98.231.18540: Flags [S.], seq 3320851465, ack 717593002, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.041962 IP 213.238.172.16.23 > 112.162.25.101.57425: Flags [S.], seq 3228028277, ack 1807270783, win 0, options [mss 1460,sackOK,TS val 3718395541 ecr 378742201,nop,wscale 7], length 0 22:10:07.046320 IP 185.90.81.156.22 > 121.18.238.109.51075: Flags [S.], seq 1429287015, ack 2347770725, win 14480, options [mss 1460,sackOK,TS val 1806276340 ecr 3494708,nop,wscale 7], length 0 22:10:07.046637 IP 185.118.143.226.62811 > 36.66.114.249.8080: Flags [S], seq 340346029, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 22:10:07.047488 IP 178.149.240.10.50448 > 213.238.170.30.80: Flags [S], seq 3978198871, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.047810 IP 213.238.170.30.80 > 178.149.240.10.50448: Flags [S.], seq 3450982954, ack 3978198872, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 22:10:07.050154 IP 185.118.142.225.16474 > 47.90.90.185.22: Flags [S], seq 3985414260, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 1297614294 ecr 0], length 0 22:10:07.055412 IP 185.89.72.69.2606 > 85.153.207.222.23: Flags [S], seq 1436143582, win 32086, length 0 22:10:07.057165 IP 104.25.25.19.80 > 213.238.171.194.47591: Flags [S.], seq 3947645944, ack 3901728852, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 10], length 0 22:10:07.064252 IP 185.171.88.56.3389 > 79.137.3.49.51540: Flags [S.], seq 1150590020, ack 2221007522, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.064570 IP 79.137.3.49.51543 > 213.238.171.243.3389: Flags [S], seq 3312534900, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.065567 IP 213.238.170.30.80 > 178.149.240.10.50452: Flags [S.], seq 4092036435, ack 1227162433, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 22:10:07.068469 IP 178.20.228.104.80 > 173.252.74.112.58654: Flags [S.], seq 1384434923, ack 2019997577, win 14480, options [mss 1460,sackOK,TS val 3430005132 ecr 3815919272,nop,wscale 7], length 0 22:10:07.069935 IP 208.146.36.220.80 > 185.182.191.68.63959: Flags [S.], seq 3879436984, ack 2417579047, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 22:10:07.073823 IP 31.187.74.10.52856 > 178.20.229.229.25565: Flags [S], seq 2074929964, win 29200, options [mss 1400,sackOK,TS val 1402888449 ecr 0,nop,wscale 7], length 0 22:10:07.074180 IP 195.211.221.116.80 > 185.118.143.184.61790: Flags [S.], seq 1549504260, ack 3248016137, win 5840, options [mss 1460,nop,wscale 9], length 0 22:10:07.078232 IP 31.187.66.246.1212 > 37.123.99.15.50090: Flags [S.], seq 2744297289, ack 2328128370, win 5792, options [mss 1460,sackOK,TS val 2739865516 ecr 1167371006,nop,wscale 9], length 0 22:10:07.078686 IP 185.118.142.10.53382 > 46.164.128.62.3389: Flags [S], seq 1089026771, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.083138 IP 74.125.200.26.25 > 213.238.166.79.50003: Flags [S.], seq 285023667, ack 4113304395, win 42408, options [mss 1380,sackOK,TS val 1429963177 ecr 821225226,nop,wscale 7], length 0 22:10:07.084416 IP 114.142.150.131.80 > 213.238.171.194.34912: Flags [S.], seq 3918590107, ack 4189166533, win 16384, options [mss 1460,nop,wscale 0,nop,nop,TS val 0 ecr 0,nop,nop,sackOK], length 0 22:10:07.084797 IP 185.118.142.125.12999 > 112.122.237.35.22: Flags [S], seq 4267847679, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 624271037 ecr 0], length 0 22:10:07.086144 IP 208.180.40.132.25 > 178.20.226.19.38151: Flags [S.], seq 2655329546, ack 2485388628, win 4380, options [mss 1460,nop,nop,TS val 1278669191 ecr 2167567286,sackOK,eol], length 0 22:10:07.088286 IP 185.118.142.9.28079 > 186.105.74.63.22: Flags [S], seq 2090494914, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 62789951 ecr 0], length 0 22:10:07.092183 IP 213.238.171.194.52673 > 104.27.174.195.80: Flags [S], seq 1343019485, win 14600, options [mss 1460,sackOK,TS val 3329676706 ecr 0,nop,wscale 7], length 0 22:10:07.092284 IP 220.132.7.41.61919 > 185.90.81.200.23: Flags [S], seq 3109704136, win 45172, length 0 22:10:07.097713 IP 222.252.14.170.7698 > 213.238.170.109.23: Flags [S], seq 26142, win 14600, length 0 22:10:07.106657 IP 128.65.196.35.22 > 178.20.228.130.37752: Flags [S.], seq 3722271856, ack 2440992154, win 14480, options [mss 1460,sackOK,TS val 2788960236 ecr 274083280,nop,wscale 7], length 0 22:10:07.108213 IP 185.118.142.124.80 > 78.188.155.132.26393: Flags [S.], seq 3249123188, ack 2877572672, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 22:10:07.113986 IP 185.118.143.184.61793 > 195.211.221.116.80: Flags [S], seq 2381684426, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 22:10:07.123428 IP 173.240.112.75.50129 > 213.238.170.30.80: Flags [S], seq 274232196, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 351114079 ecr 0,sackOK,eol], length 0 22:10:07.126699 IP 94.102.9.97.3389 > 37.123.99.57.52801: Flags [S.], seq 3073691605, ack 93046053, win 64000, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0 22:10:07.128418 IP 213.238.172.130.3756 > 82.94.210.34.25: Flags [S], seq 3541792627, win 65535, options [mss 1460,nop,nop,sackOK], length 0 22:10:07.129283 IP 213.238.166.76.59509 > 216.82.242.36.25: Flags [S], seq 385646225, win 14600, options [mss 1460,sackOK,TS val 821225937 ecr 0,nop,wscale 7], length 0 22:10:07.130022 IP 64.233.184.26.25 > 213.238.166.76.57086: Flags [S.], seq 4135378003, ack 2141943155, win 42408, options [mss 1380,sackOK,TS val 1280654113 ecr 821225869,nop,wscale 7], length 0 22:10:07.135859 IP 104.27.174.195.80 > 213.238.171.194.52674: Flags [S.], seq 3208172504, ack 3052400146, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 10], length 0
I cannot seem to remove an adress book entry from my SRX220. I use the Gui and the change won't commit. So It try from the CLI. My Config is thus (without x's):
security-zone Internet {
address-book {
address Dave_home 70.x.x.x/32;
I want to remove Dave, been using:
delete security zones security-zone internet address-book address-set address Dave_home 70.x.x.x/32
Router comes back "No entry exists". I have others in there to delete as well. Same issue on them. I've even just tried on the address 70.x.x.x