SRX

Hello,

I've trying to setup a cluster of SRX210 and ingest an IP via Hub 3.0 in modem mode, which works fine cloning the mac on the reth0 interface (reth0 outside, reth1 inside). Unfortunately, I can't ping Google from the firewall.

This same setup worked previously with no cluster with only one unit, although with some random issues where I lost the public IP on the firewall. Overall, it seems like VM Hub 3.0 doesn't work rock-solidly in modem mode, and also it depends a lot on the hardware you behind. 

The first setup was to have PFsense virtually which worked perfectly, but now I'm not sure whether it's the firmware on the Hub or it's something wrong on my SRX configuration.

What annoys and confuses me is the fact that I'm getting (Access-internal/12), where I received "default" (if I remember correctly when I had only one single unit). Another fact is that I'm stripping the VLAN 100 tag from the switch to the Hub3 but tagging it back on the LACP to the SRX cluster. I can see ARP from the street VM cabinets, and I get the public IP correctly although something is wrong as it doesn't work. This same method worked correctly.

root@firewall_node01> show route

inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Access-internal/12] 00:13:56

                    > to 82.6.88.1 via reth0.100

Any help would be great.

Thanks,

Alberto.

Since you get the default route I assume you are also getting the dhcp ip address on the reth interface too.  That seems to validate the basic connection.

How you are physically connecting the cluster to the modem?

And what exactly do you mean by "LACP on the SRX cluster"? 

Note that reth are redundant ethernet and NOT an Aggregated Ethernet bundle.  These are an active/passive ethernet pair and not an LACP AE configuration.

Thansk for your reply Steve.

The cluster of SRX210 is connected to a TP LINK switch, reth0 to a LACP and reth1 forming a second LACP on that switch. That TP LINK switch has several VLANs, one of them 100, which is the external Virgin Media one. On reth0 the LACP is tagged with that VLAN 100 and is the native VLAN.

The VM Hub3 is connected to that same switch to a single port, configured as follows:

• VLAN 100 is native
• VLAN 100 tagged on traffic coming to the switch, therefore is the reth0 interface
• VLAN 100 is untagged (ot it's flag stripped) on traffic going out the switch towards the Hub 3.0

This same setup method of VLAN tagging and untagging was working fine with a single unit. I'd bet this is a VM Hub3 dislinking of a Juniper device behind it. Although, as I mentioned before I think I received a [default] route when I had a single unit. It's very frustrating to see everything fine on PCAPs and even so not being able to ping the Internet.

Thanks,

Alberto.

Can you post the configurations of the connecting ports on the SRX and the switch.

Is this the example you are following to configure AE with LACP on the chassis cluster.

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-chassis-cluster-redundant-ethernet-lag-interfaces.html

Hello,

Thanks for your support and reply.

I managed to get it working. Apparently it was an issue with the booting order of the Hub and SRX cluster, plus my suspicion of what could be a problem with ARP expiration on the street cabinet.

Now I can failover from one node to the other and works fine with only a few seconds of outage. Unfortunately this turns out to have uncovered other problems. On my TPLINK switch whenever I use the default hash algorithm for LACP, which is SRC MAC+ DST MAC, it turns out some parts of the network work and some other don't, in example and very bizarrely my mac and my phone do have Internet connectivity, my partner's and my Ipad don't. I also have access to ESX Vsphere host (through a LAG) and externally through my VPN appliance.

When I switchover to hash algorithm DST IP, my wireless devices all work, but I don't have connectivity from the outside through my VPN appliance. I don't see any configuration on Juniper's side to tune the LACP and make him match with the switch's side.

Does this make sense? Any thoughts/recommendations?

Thank you very much.

Alberto.

Can you post the output of these status commands for the ae bundles

show lacp interfaces reth0

show lacp interfaces reth1

And the interface setup

show configuration interfaces reth0

show configuration interfaces reth1

Hello,

Thanks for your reply.

Here they are:

root@firewall_node01> show lacp interfaces reth0
Aggregated interface: reth0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/0 Actor No No Yes Yes Yes Yes Fast Passive
ge-0/0/0 Partner No No Yes Yes Yes Yes Slow Active
ge-2/0/0 Actor No No Yes Yes Yes Yes Fast Passive
ge-2/0/0 Partner No No Yes Yes Yes Yes Slow Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/0 Current Slow periodic Collecting distributing

ge-2/0/0 Current Slow periodic Collecting distributing

root@firewall_node01> show lacp interfaces reth1
Aggregated interface: reth1
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Passive
ge-0/0/1 Partner No No Yes Yes Yes Yes Slow Active
ge-2/0/1 Actor No No Yes Yes Yes Yes Fast Passive
ge-2/0/1 Partner No No Yes Yes Yes Yes Slow Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/1 Current Slow periodic Collecting distributing
ge-2/0/1 Current Slow periodic Collecting distributing

root@firewall_node01> show configuration interfaces reth0
description "VLAN Trunk to Untrust";
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
minimum-links 1;
lacp {
passive;
}
}

....

root@firewall_node01> show configuration interfaces reth1
description "VLAN Trunk to Internal Subnets";
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
minimum-links 1;
lacp {
passive;
}
....

Thanks,

Alberto.

Your configure shows that you don't have a AE bundle configured here only the standard redundant ethernet.  To setup an AE you would be using two interfaces on each SRX.  This standard configuration is not a LAG.

So on the switch side you will remove the ae configuration and configure both ports as either an access port if this is a single untagged vlan or a trunk port if this is a multiple vlan tagged interface.

The traffic problems you are seeing are because the switch expects both these interfaces to be members of the same ae bundle they are not.  Each side would be it's own ae bundle if you used the 4 ports with two on each side and you would configure two ae bundles to match on the switch side.

Hello Steve,

Thank you so much for your help, that made trick and makes total sense! My bad

Either I use the same ports on the same device for the LAG or you need to use independent trunk ports for the current installation I have. The performance now is great and no downtime at all.

Another test I have in mind is to try an IPS device for scanning outgoing and incoming traffic. I have only one routing instance, but I think I'd need an external one and a internal one to be able to route traffic through that IPS having backup static routes too. Does that make sense?

Thank you so much.

Alberto.

The exact topology and insertion of IPS vary by the company.  They typically want to be inline with the traffic to enforce the blocks that the signatues find in traffic.

And they come in either transparent layer2 insertions or layer 3 where the IPS itself is a hop in the chain.

Do you have the device model and recommended deployment?

Hello Steve,

Thank you so much for replying and your interest on this.

The fact is that I'm running this at my home lab, as I have old SRXs that I bought from my company. I'm interested in setting up perhaps not an entirely IPS device by definition, but definitely something I can filter my wireless traffic on, more intelligently than if it were a PFSense for example. In the past and when I didn't have this cluster setup, I tried Sophos XG virtualized on an ESXi but turned out I was creating loops when trying to achieve an IPS jump/routing. This is the reason I'm interested now in perhaps with a dual nic NUC run a proper traffic scanner/IPS in conjuction with my other network devices.

I only allow externally port 8443 and 10051 for TLS/SSL VPN and monitoring purposes, but I'd like to know what is knocking at the door, either on those ports or any others.

Does the above make sense to you?

Many thanks,

Alberto.

The details on how to get the flow to run through the desired inspection device are going to vary depending on how that device works.  So the first step will be to pick the technology you want to use for the inspection.

From there we get the details on what flow type is required and can then setup either in line or specific port diversions and changes that are required by the inspection tool.