Hi ,
Actually we are using the srx 210 as external gateway and allowed the policy as untrust to trust any and in our core firewall srx 240 we allow only the things we want.
After adding the policy in srx210 to deny everything and allowing the policies we want, those processes have been gone to zero now.
Here is the output you have asked for :
Hello Gautam,
I'm glad the issue is resolved.
As you might already know, it is not recommended to allow all the traffic from Untrust to Trust and I guess due to that traffic rate went high on the SRX filling up the resources.
Hi ,
I think the cpu utilization is not constant it came back again in syslog:
I'm having trouble seeing the entire picture. Can you please provide config for your interfaces, routing-instances and routing-options as I cannot see which table from where vlan.3 and vlan.401 originally is sourced from.
Thanks
Hello all,
we are running two SRX1400 as a cluster.
After running for quite some time without issues, suddenly the secondary node lost all his network interfaces.
Checking the cluster hardware it seems that the secondary node has lost its FPC0, or at least the connection to it.
admin@node0> show chassis hardware
node0:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
...
FPC 0 REV 19 750-031019 XXXXXXXX SRX1k 10GE SYSIO
PIC 0 BUILTIN BUILTIN 6x 1GE RJ45 3x 1GE SFP 3x 10GE SFP+
Xcvr 6 REV 02 740-013111 XXXXXXX SFP-T
Xcvr 7 REV 02 740-013111 XXXXXXX SFP-T
Xcvr 8 NON-JNPR XXXXXXXXXXX SFP+-10G-SR
Xcvr 9 NON-JNPR XXXXXXXXXXX SFP+-10G-SR
...
node1:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
...
FPC 0 REV 19 750-031019 YYYYYYYY SRX1k 10GE SYSIO
PIC 0
...
All productive interfaces are located on this FPC0.
In addition to that, the productive redundancy group 1 was running on secondary node at that time and we lost complete connectivity to and through that device.
Interface monitoring was configured, but it did not execute a failover.
We had to do a manual failover to get the connections working again.
Currently I am planning a reboot of the secondary node, to see if the system can recognize FPC0 again completely.
Apart from that, I wonder, why the interface monitoring did not help to do a fail-over? Any hints?
Thanks in advance.
Hello Hermod,
I would suggest to re-seat the SYSIO and if the issue persists again then RMA has to be initiated.
Regarding Interface monitoring, Have you configured the weights properly? i.e. Your configured weight will be decremented with global weight 255 and it has to reach 0 in order to initiate a failover.
Send me the output of user@host> show configuration chassis cluster | display set
Thanks for your reply.
This is the requested output:
set chassis cluster control-link-recovery
set chassis cluster reth-count 12
set chassis cluster redundancy-group 1 node 0 priority 200
set chassis cluster redundancy-group 1 node 1 priority 100
set chassis cluster redundancy-group 1 preempt
set chassis cluster redundancy-group 1 interface-monitor xe-0/0/8 weight 255
set chassis cluster redundancy-group 1 interface-monitor xe-0/0/9 weight 255
set chassis cluster redundancy-group 1 interface-monitor xe-4/0/8 weight 255
set chassis cluster redundancy-group 1 interface-monitor xe-4/0/9 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/0 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-4/0/0 weight 255
set chassis cluster redundancy-group 0 node 0 priority 200
set chassis cluster redundancy-group 0 node 1 priority 100
Edit2: The xx-4/y/z interfaces are those from the "disappeared" FPC0 on the second node.
Edit1: I had an idea that if interface-monitoring can only work for "existing" interfaces, that could explain why nothing happened. The interfaces disappeared and are not accessible anymore... But my knowledge of SRX isn't that deep... I am only guessing here.
Hi Hermod,
This seems like a strange issue.
Even though the interfaces disappear on the secondary node, the jsrpd should trigger a failover. I have seen this behaviour in older Junos version where the jsrpd might stuck and didn't trigger a failover due to a software bug.
I would suggest you to stay on the recommended Junos version.
Yes of course
# show interfaces vlan unit 3
family inet {
filter {
input lan-filter;
}
address 192.168.0.78/24;
}
# show firewall family inet filter lan-filter
term to-ftd {
from {
source-address {
192.168.0.0/24;
}
}
then {
routing-instance to-ftd-route-table;
}
}
term default {
then accept;
}
# show interfaces vlan unit 401
family inet {
address 10.16.1.1/30;
}
# show routing-instances
to-ftd-route-table {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 10.16.1.2;
}
}
}
# show routing-options
interface-routes {
rib-group inet to-ftd-fbf-group;
}
static {
route 0.0.0.0/0 next-hop 2.2.2.2;
}
rib-groups {
to-ftd-fbf-group {
import-rib [ inet.0 to-ftd-route-table.inet.0 ms-exchange-route-table.inet.0 ];
}
}
# show route
inet.0: 84 destinations, 86 routes (83 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 8w3d 05:02:20
> to 2.2.2.2 via ge-0/0/15.0
10.16.1.0/30 *[Direct/0] 5w0d 20:02:39
> via vlan.401
10.16.1.1/32 *[Local/0] 25w4d 02:38:27
Local via vlan.401
192.168.0.0/24 *[Direct/0] 5w0d 20:02:39
> via vlan.3
192.168.0.78/32 *[Local/0] 35w3d 20:57:55
Local via vlan.3
...
...
to-ftd-route-table.inet.0: 76 destinations, 78 routes (75 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 5w0d 20:02:38
> to 10.16.1.2 via vlan.401
10.16.1.0/30 *[Direct/0] 5w0d 20:02:39
> via vlan.401
10.16.1.1/32 *[Local/0] 5w0d 20:02:39
Local via vlan.401
192.168.0.0/24 *[Direct/0] 5w0d 20:02:39
> via vlan.3
192.168.0.78/32 *[Local/0] 5w0d 20:02:39
Local via vlan.3
...
...
# show security zones security-zone EST
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
…
vlan.3;
vlan.401;
…
}
Thanks for the configuration. It's like I suspected but good to get confirmed.
First of all - to avoid any misunderstandings: firewall filters equals to access-list on eg. Cisco devices. The actual firewall rules are named 'security policies'. The security policies doesn't force return traffic back via the receiving interface for the initial flow.
The SRX uses the route table as it's source of truth for next hop of the traffic and in your case both vlan.3 and vlan.401 are placed in the global routing table named inet.0 with a next-hop for 0/0 towards 2.2.2.2 on ge-0/0/15.0 - so obviously a packet destined for 217.66.159.146 will go out this way even that it's received via vlan.401.
You have then solved the assymetrical routing via filterbased forwarding, where you via a firewall filter (access-list) manipulates the next hop of the traffic with source 192.168.0.0/24 on vlan.3. This is also just as expected.
Your options are as follows:
1) Create hide-nat in the Cisco FTD so traffic from 217.66.159.146 towards 192.168.0.0/24 are nat'ed behind 10.1.16.2. That way the SRX can send the return traffic correctly back to the FTD without configuring filter-based forwarding.
2) Create a seperate routing-instance (type virtual-router) on the SRX where you place vlan.401 and vlan.3.
There you configure the default route towards 10.1.16.2. If you need to reach other interfaces or routes from the inet.0 route table, you can import these into the new routing-instance. Remember to include import/export filters so the default route from inet.0 doesn't show up in your new routing-instance.
3) Keep using your filter-based forwarding with a firewall-filter on vlan.3. It's perfectly fine, security policies are still evaluated. Remember - this is just changing your next-hop, not disabling the firewall process (flow daemon). To disable the firewall process, the firewall filter should include terms with "then packet-mode". Otherwise security is still being enforced.
I hope this clarifies. Let us know if you have further questions.
The solution suggested by Nellikka fixed it for me.
Hi all ,
I have a problem when config dhcp-local-server.
I create 2 address-assignment pool , one for dynamic assign (guests) , one for static assign (servers or devices).
Like this
pool static{
family inet {
network 192.168.2.0/24;
range static{
low 192.168.2.0;
high 192.168.2.0;
}
dhcp-attributes {
name-server {
8.8.8.8;
1.1.1.1;
8.8.4.4;
}
router {
192.168.2.1;
}
}
host reversed {
hardware-address ff:ff:ff:ff:ff:ff;
ip-address 192.168.2.0;
}
host server {
hardware-address aa:bb:cc:dd:ee:ff;
ip-address 192.168.2.2;
}
}
}
pool dynamic{
family inet {
network 192.168.1.0/24;
range dynamic{
low 192.168.1.2;
high 192.168.1.254;
}
dhcp-attributes {
name-server {
8.8.8.8;
1.1.1.1;
8.8.4.4;
}
router {
192.168.1.1;
}
}
}
}
Then two pool in same interface , when I connect host server to SRX240 , It get IP 192.168.1.2 .
What should I do to let host server can get 192.168.2.2 ?
wrote: 3) Keep using your filter-based forwarding with a firewall-filter on vlan.3. It's perfectly fine, security policies are still evaluated. Remember - this is just changing your next-hop, not disabling the firewall process (flow daemon). To disable the firewall process, the firewall filter should include terms with "then packet-mode". Otherwise security is still being enforced.
But it doesn't work as expected. This filter does not work for responses from 192.168.0.115. This filter works only if the initiator of the tcp connection is the server 192.168.0.115. But if this server is repsponder, that is, when it responds with a tcp syn ack packet to client, then this firewall filter does not work and the packet is sent according to inet.0. The result is asynchronous routing.
But if i enable packet mode, as you say, then this filter starts working correctly, and tcp syn ack are sent from server to client via to-ftd-route-table.inet.
And I cannot understand why this is happening
Hi,
The interface's subnet and DHCP pool IP addresses should be in the same subnet. From the below KB article, it is mentioned that "Clients are assigned addresses from pools with subnets that match the interface on which the DHCPDISCOVER packet is received" - https://kb.juniper.net/InfoCenter/index?page=content&id=KB21909
You can also check the following forum link where another person confirmed that it won't work - https://forums.juniper.net/t5/SRX-Services-Gateway/SRX-DHCP-Server-not-distributing-different-subnets/m-p/479955#M57616
Ummm,
But I set two IP in same interface , 192.168.1.1 and 192.168.2.1 , DHCP server on it too.
Can you share the configuration?
pool static{
family inet {
network 192.168.2.0/24;
range static{
low 192.168.2.0;
high 192.168.2.0;
}
dhcp-attributes {
name-server {
8.8.8.8;
1.1.1.1;
8.8.4.4;
}
router {
192.168.2.1;
}
}
host reversed {
hardware-address ff:ff:ff:ff:ff:ff;
ip-address 192.168.2.0;
}
host server {
hardware-address aa:bb:cc:dd:ee:ff;
ip-address 192.168.2.2;
}
}
}
pool dynamic{
family inet {
network 192.168.1.0/24;
range dynamic{
low 192.168.1.2;
high 192.168.1.254;
}
dhcp-attributes {
name-server {
8.8.8.8;
1.1.1.1;
8.8.4.4;
}
router {
192.168.1.1;
}
}
}
}
ge-0/0/1 {
unit 1 {
family inet {
address 192.168.1.1/24;
address 192.168.2.1/24;
}
}
}
In this case, I think SRX is using 192.168.1.1 as the Primary IP address and that's the reason IP address is assigned from this pool. If you would like to use 192.168.2.1 then you have to set the primary knob under interfaces hierarchy to make it as DHCP server.
Apart from this, I don't think we can make this work in the same interface.
Still the same problem with 12.3X48-D105
Hi ALL,
I would like to setup IPSec client to site VPN with client Ubuntu 20.04 with vpnc.
https://askubuntu.com/questions/488435/cisco-vpn-configuration-steps
I would like to know ... are there any SRX site setup example for reference !?
According to Juniper Networks youtube channel ... they only have SRX to Pulse Secure for Windows 10.
Cheers,
Edwin
