The article you're referring to is simply setting up a trunk between 2 switches.
Please explain the logical scheme. Where are the interfaces located (
ge-0/0/0, ge-0/0/1, ge-0/1/0) which are mentioned in the configuration
below (which side of the switch?)?
The configuration samples in your question are placed on the interface connecting the two switches.
Do I understand correctly, that the Trunk should be only between the
two EX2200 switches? Between the SRX and switch should be two
separated links (from interface ge-0/0/1 (fxp1) and from any ge-0/0/x
(fab), correct?
Your understanding is correct. Below is a slightly modified diagram.
SRX240--------EX2200=======EX2200------SRX240
^ ^ ^
| | |
Access Trunk Access
Port Port Port
Do you need the server to also access the public network or only reply to requests from the public network?
On the first case you use static nat (bidirectional NAT), on the second you use destination nat.
Regarding your ping tests you're trying to ping an IP that, due to the proxy-arp config, is configured to respond only from the ge-0/0/0 interface. Maybe you could try to ping it like this: ping 10.129.166.135 source 10.129.166.132
, but I'd recommend to reconfigure the "natted" IP to the server since it will be easier to troubleshoot.
I also noticed that the vlan.60 interface is not configured in the trust zone, so besides other issues, all the traffic to/from the vlan.60 subnet will be blocked and the nat config won't be applied.
As a side note, I have no idea what type of public network you're connected to but the host-inbound-traffic configuration on the wan security zone should be reduced to the absolute minimum or, if possible, removed as this only controls the traffic to the firewall itself (for example, to allow a ssh connection or to ping the firewall from the public network).
proposed solution with destination nat + port-forward
This example/solution will use the address of the wan interface and map a port (5000) to the port 22 (ssh) of the internal address:
set security nat destination pool DestinationNatVideo address 192.168.3.100/32
set security nat destination pool DestinationNatVideo address port 22
set security nat destination rule-set RuleSetVideo from zone wan
set security nat destination rule-set RuleSetVideo rule r1 match destination-address 10.129.166.132/32
set security nat destination rule-set RuleSetVideo rule r1 match destination-port 5000
set security nat destination rule-set RuleSetVideo rule r1 then destination-nat pool DestinationNatVideo
You can also remove this set security nat destination pool DestinationNatVideo address port 22
and it should map the port 5000 to all services of the internal IP (it's better to map one port per service instead of leaving everything open/connectable).
The version that's installed in your device is a bit old and maybe it doesn't support nat very well (or just some parts of it) so YMMV.
Best Answer
Things you should be aware of: SRX HA links communicate using jumbo frames and multicast addresses. So to make this work you need at least the following changes on the EX switches:
Configure a jumbo MTU on the HA links and the links between the EX switches. This will enable jumbo frames to go trough the switch infrastructure.
Deactivate igmp-snooping for the HA VLAN or if not needed delete it completely. If you leave it enabled the switch will not forward the multicast frames because there are no IGMP messages to tell the switch which port is listening for these frames.
or
Over which media you connect the switches with each other is not important, you can use copper or fiber as you wish. I would use an
ae
bundle interface with two or more links to reduce the chance of one link failure killing the whole connection between the switches. Don't forget to enable LACP on the ae bundle. If possible have the two links take different routes to prevent someone cutting both fibers at the same time.This being said, if possible I would always suggest directly connecting the HA links of any firewall device. This reduces the risk that a problem on the switch (hardware failure, software bug, human error) will cause you a split-brain situation (both firewalls become master) which will certainly ruin your day (BTDT).