Hi,
Is it on MX240 we still can disable the USB port on RE?
Thanks
↧
Re: SRX 340 CONSOLE PORT
↧
Re: SRX 340 CONSOLE PORT
Did a quick test on an mx240 and the hierarchy system processes is there hidden but usb-control is not a valid option.
↧
↧
SRX1500 root password reset
Does anybody know how to reset root password for srx1500. The srx boot to wind river linux instead the common junos like srx345.
↧
Re: SRX1500 root password reset
Good Day,
Hope this will help you: https://kb.juniper.net/InfoCenter/index?page=content&id=KB15725&actp=METADATA
↧
Re: SRX1500 root password reset
Hi Yen,
Hope youre doing good.
Please check the following technical documentation and refer the section "Recovering the Root Password for Junos OS Evolved" - https://www.juniper.net/documentation/en_US/junos/topics/topic-map/recovering-root-password.html#jd0e563
↧
↧
Re: SRX1500 root password reset
Password recovery is same for all the platforms. May be the issue is related to this PR: https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1381653
↧
Re: SRX1500 root password reset
Yes correct. There is no option to boot into single mode.
↧
Re: Tip: Two factor authentication managing SRX via web or cli
Hello,
Is that all the commands you did for DUO? Where did you upload the zip file that DUO asks us to upload on SRX?
All online tutorials are via J-Web and that's garbage; page hangs and I can't find the tabs online tutorials are pointing towards.
Can you please share DUO part of configs that needs to be on SRX for Dynamic VPN ?
Thank you
↧
Re: SRX1500 root password reset
Hi Yen,
No single user mode means most probably you have marked your console as insecure from the configuration.
Do you have the device old RSI or configuration?
If yes, Check for the following command:-
set system ports console insecure
If so you wont be able to recover the same using console boot and the only option to recover is re-install the OS using USB.
-RAhul
↧
↧
esp sec tunnel protocol
Hi all,
what is the reason the follwing mes log is generating? And what troubleshooting should be done and what solution to address?
RT_IPSEC: RT_IPSEC_REPLAY: Replay packet detected on IPSec tunnel on xe-1/1/2.0 with tunnel ID 0x4000100! From 10.10.10.10 to 150.145.260.18/552, ESP, SPI 0x293be11c, SEQ 0x169af.
↧
Re: replay errors
This could be an attack or the result of network congestion or fragmentation issues. This kb outlines the possible causes and options.
https://kb.juniper.net/InfoCenter/index?page=content&id=KB29580
↧
Re: replay errors
Hi Arix,
The reason you're seeing this log message is due to the Replay attack, where the ESP packet is intercepted, then modified and re-transmitted back.
However, it may not be due to an attack but other factors such as congestion, out-of-order packets, etc.
As spuluka stated, please refer to the KB article for more explanation and let us know if you have further queries.
↧
Re: replay errors
Is it possible to get tcp 3handshake sessions via tcpdump from the shell to see ESP packet behaviours? Or it is nt possile?
tried the following but didn't work:
tcpdump -in xe-1/1/1 -s 5000 -w /var/tmp/capture.pcap -c 1000
BIOCSETIF: n: Device not configured
↧
↧
Re: SRX1500 root password reset
Yen,
What Junos code are you on?
Per the PR suggested up here, PR1381653, the codes this is fixed in are:
| Release | junos |
| 18.2R3 | x |
| 18.3R2 | x |
| 18.3R3 | x |
| 18.4R2 | x |
| 17.4R3 | x |
| 19.1R2 | x |
| 19.2R1 | x |
Reinstalling the OS would do the trick.
Cheers
Pooja
↧
SRX210 & Azure VPN
Hi,
We have two VPN tunnels to Azure and we're experiencing an issue were traffic stops passing through the Azure side of the tunnel.
Both tunnels stay up, just not passing traffic.
I can see the traffic leaving from our side of the tunnel, just not working on Azure.
Azure support have no idea whats going on and want me to engage Juniper.
Does anyone have any ideas?
Thanks.
↧
Re: SRX210 & Azure VPN
wyze,
How are you confirming that you are sending traffic to them?
You can run the following command in order to confirm if the SRX is encrypting data via that VPN:
user@host> show security ipsec statistics index [tunnel_index] ESP Statistics:Encrypted bytes: 952 Decrypted bytes: 588Encrypted packets: 7 Decrypted packets: 7
The tunnel_index highlighted above can be found by confirming the index of the tunnel towards Azure running a "show security ipsec security-associations" command.
Also you can create a firewall-filter with a counter to tell if the SRX is sending ESP/encrypted packets towards Azure:
1. Create filter: #set firewall family inet filter FILTER term ESP_COUNTER from destination-address [Azure_Public_IP] #set firewall family inet filter FILTER term ESP_COUNTER from source-address [SRX_Public_IP] #set firewall family inet filter FILTER term ESP_COUNTER from protocol esp #set firewall family inet filter FILTER term ESP_COUNTER then count ESP_PACKETS-TO_AZURE #set firewall family inet filter FILTER term ESP_COUNTER then accept #set firewall family inet filter FILTER term ALLOW_ELSE then accept 2. Apply filter: #set interfaces [SRX_External_Interface] unit 0 family inet filter output FILTER 3. Commit changes for only 5 minutes #commit confirmed 5 4. Check the counter: > show firewall
If the counter increases you have another proof that the SRX is sending encrypted traffic to Azure. If Azure tells that they are not receiving any encrypted packets, then you will have to engage your ISP in order to confirm why this traffic is being dropped/not reaching Azure.
If you see ESP packets being sent by the SRX, you could try rebooting the ISP modem in front of the SRX.
↧
Re: replay errors
Hi,
Since this is ESP there is no TCP handshake involved. As regards the packet-capture, I would suggest using the packet-capture functionality in the firewall.
Which is the firewall model you have? Depending on this you can do the pcap via datapath-debug (For SRX-HE) or forwarding-options (For SRX-Branch). The Source and destination IP you need to use in the filter would be the VPN end-points. This would capture ESP traffic.
PCAP on SRX-HE: https://kb.juniper.net/InfoCenter/index?page=content&id=KB21563
PCAP on SRX-Branch: https://kb.juniper.net/InfoCenter/index?page=content&id=kb11709
Hope this helps. Regards,
Vikas
↧
↧
Re: SRX210 & Azure VPN
Hi epanigua,
Thank you the reply. Will try what you have suggested.
When I'm told users cant access a virtual machine in Azure, I check both the SRX and Azure to see what the status of the tunnel is, and both sides say Up. I then ask them to initiate traffic and I run the below:
root@SRXFW> show security flow session destination-prefix 10.0.7.6
Session ID: 11712, Policy name: jump05-to-vpn-azure/149, Timeout: 18, Valid
In: 172.18.41.64/56193 --> 10.0.7.6/3389;tcp, If: vlan.1841, Pkts: 2, Bytes: 104
Out: 10.0.7.6/3389 --> 172.18.41.64/56193;tcp, If: st0.10, Pkts: 0, Bytes: 0
Total sessions: 1
Azure support say they can see the SRX not replying, but I cant see anything.
Can attach some logs if it will help.
Thanks.
↧
session
Hi,
Why a number of outputs of >sh sec flo session have only one direction -in not both In and Out...Others have both directions In and Out.... ?
For instance,
Session ID: 76, Policy name: N/A, Timeout: N/A, Valid
In: 159.100.210.173/0 --> 133.115.240.110/0;esp, If: xe-1/0/1.0, Pkts: 0, Bytes: 0
↧
Re: SRX210 & Azure VPN
wyze,
Can you elaborate on your topology so that I can better understand the output? Is it like this?:
172.18.41.64------SRX------------INTERNET----------Azure---------10.0.7.6
If so, then the output shows that the SRX is not seeing the reply from Azure VM over the VPN.
Besides the tests mentioned on my first comment, you can try a flow traceoptions to confirm if the SRX is processing the packets coming from Azure:
1.Configure the traces #set security flow traceoptions file TRACE #set security flow traceoptions flag basic-datapath #set security flow traceoptions packet-filter TEST source-prefix [Azure_VM_IP] #set security flow traceoptions packet-filter TEST destination-prefix [Internal_IP] 2. Commit #commit 3. Send traffic from Azure side 4. Check the file >show log TRACE
You can attach the outputs from the suggested commands as well.
↧