Hi all, So today I noticed that the destination addresses listed under firewall info for my dashboard had changed, and this explains nicely why some devices have been having a hard time connecting to the dashboard. My question is - for MX devices, what source address would they use management connections on TCP/7734, 7752 and UDP/7351, 9350-9351?  I can packet capture and see this traffic on the WAN interface, but not always the LAN interface (espcially the UDP traffic).  This might just be a coincidence because I am capturing at different times, or does the MX originate the UDP traffic from the WAN address (i.e. not one of the LAN subnets)? Thanks in advance. ... View more

Hi, I have a question on setting the management VLAN on the MS series switches.  Imagine that the switch uplink is connected to a trunk port on another switch with the following config (U-101, T-10,20,30,50,999) - Native (untagged) VLAN-ID 101 (this is a parking lot / blackhole empty VLAN) - Tagged VLANs 10,20,30,40,999 - Note that management should be tagged in-band management on VLAN 999   What's the difference between setting the VLAN-ID to 999 in the front-page switch settings on the dashboard, and leaving the management VLAN under switch settings as VLAN1?  The way I understand this, the management VLAN under switch settings is to set the management VLAN network wide - for all switches - and setting the VLAN under LAN IP would over-ride this by exception.  Did I understand this correctly?    ... View more

I'm working through an issue with MX64 as a client VPN server behind a 3rd party (Fortigate) firewall.  I have UDP/4500 and UDP/500 forwarded from the WAN interface of the other firewall to the MX64.  I've looked at packet captures and can see the following: 1) SA completes (client to server ephemeral port 57234 to 500) 2) KE completes (ephemeral port 57234 to 500) 3) ID - client sends ID on ephemeral ports 35121 to 4500, but MX replies with source port 4500 to destination 4500 - i.e. it doesn't reply with dst port 35121 - that the session is established on - so it gets dropped.   I ran a test with another MX NATted behind another firewall, and this worked fine.  The difference was at step 3) - this MX replied from 4500 back to the ephemeral DST port (42854 in this case), then established the connection and proceeded to ESP.   My question is, in the first non-working scenario, why is the MX64 replying from 4500->4500 instead of  4500->35121? I can't fund any reason why it's not behaving in the same way as the working example.  ... View more