![]() ![]() ” do not recommend configuring chassis cluster IP monitoring on Redundancy Group 0 (RG0) for SRX Series devices.” But because of a remark on this Juniper website: I can not find anything in the documentation that states that ip-monitoring and interface monitoring on a Reth that consists of a LAG is not supported. On this RG, both IP monitoring as well as Interface monitoring was configured, which apparently are both Dataplane functionalities. In other words: the Primary Node Reth could NOT FAILOVER. Not very nice, as it mean that the secondary node declared the Reth on that node unfit for action. that started intermittently failing for inexplicable reasons. The way it is supposed to work, is that the secondary node should on a regular bases verify connectivity to the monitored IP address (usually the default gateway/router) via a secondary IP address.Īnd for some reason. during extensive Systems Acceptance Tests, we found out that on regular occasions, the second node that was NOT primary for the Reth, suffered from ip-monitoring reachability problems when testing the internet connectivity via ip-monitoring. Just like the documentation says it should. This LAG was connected to a 2nd LAG on the same switch. In case of a failure, they Reth should failover to the second node where the 2nd part of a 4 cable LAG was configured. Receive notifications of new posts by email.During a recent project, I built a Juniper SRX cluster where a Reth connected via a LAG to a switch, which in turn is connected it to the Internet. Though I thought this would be impossible because IPsec always needs IKE, the VPN still worked.) (However, I had some situations in which the first status bubble was green (IPsec) while the second was red (IKE) after a while. If everything is alright, the IPsec tunnels pane on the Palo Alto firewall should show two green status bubbles: Under the Advanced tab insert the PSK and the Custom Phase 1 Proposal:Ī new tunnel interface with its IP address:Īnd the new AutoKey IKE entry which references to the gateway and to the tunnel interface (under the Advanced tab):įinally, add the static route without a next hop IP address but with an interface of the configured tunnel: At first, add the additional P1 and P2 proposals:Īdd a new Gateway with the correct IP address of the other side. The steps are almost the same for the Juniper firewall. (And don’t forget to commit )) Juniper SSG ![]() That is, the policy rule should look like the following: However, the Palo Alto firewall also needs a security policy entry on the untrust interface that permits the IKE and IPsec (ESP) packets to come in from the other tunnel endpoint and to go out from its own interface. ![]() Also add the tunnel monitor with the destination IP address of the other side of the tunnel interface:įinally, add a new static route for the remote network with a Next Hop selection of “None”: Enable the “Replay Protection” which is enabled by default on the Juniper firewall. ![]() Tunnel Interface with its IP address, virtual router and security zone:Ĭreate a Monitor Profile for the tunnel monitor:Īnd then the IPsec Tunnel. Palo AltoĪt first, create the IKE and IPsec Crypto Profiles:Ĭreate (add) the IKE Gateway with the outgoing interface and IP address, the pre-shared key (PSK) and the specific IKE Crypto Profile: The zones on both firewalls are already configured – in my lab they are called “vpn-s2s”. In order to use the most secure crypto algorithms, I configured both phases with AES-256, SHA-1, and Diffie-Hellman group 5 (PFS). The SSG 5 runs with firmware version 6.3.0r14.0 while the Palo Alto PA-200 has PAN-OS 5.0.8 installed. The following figure shows my laboratory IP address scheme. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |