Hello TheDisciple,
The disconnects are sometime a few seconds apart and sometimes a day or two apart. They seem completely random.
Really annoying
Thank you though! Out of interest how would I see how long the lease has left?
Many thanks,
Hello TheDisciple,
The disconnects are sometime a few seconds apart and sometimes a day or two apart. They seem completely random.
Really annoying
Thank you though! Out of interest how would I see how long the lease has left?
Many thanks,
Do we know if the AD was connected when the issue happens? Also is this issue specific to this user?
show services user-identification active-directory-access domain-controller status
THE INTERNET /28 & /32 ---------------(untrust public interface)SRX(ADMIN_DMZ)--------------INTERNAL_SERVER
Im having an issue configuring destination NAT, if someone can give a hand it'd be greatly appreciated.
A public /28 and /32 needs to connect to our internal address of 10.132.6.128/32 on port 22 from a public address that is not an address of the untrust zone of the SRX. The address on ADMIN_DMZ is also a public address.
THE INTERNET /28 & /32 ----------(untrust public 72.x.x.x)SRX(65.x.x.x ADMIN_DMZ)---------INTERNAL_SERVER (10.132.6.128/32)
I get a few translation hits but they're all failed sesssions. The policy from the untrust to ADMIN_DMZ has the correct source, destination and ports. I've also got proxy-arp, which I believe is needed after reading something on a few forums.
SRX# show security nat destination pool dnat { address 10.132.6.128/32 port 22; } rule-set dst-nat { from zone untrust; rule rule1 { match { destination-address 65.x.x.x./32; destination-port { 22; } } then { destination-nat { pool { dnat;
SRX# show security policies from-zone untrust to-zone ADMIN_DMZ policy 63100 match { source-address [ auditor officeip ]; destination-address auditor-rfc; application [ cp-40814 junos-ping junos-ssh ]; } then { permit; SRX# show security address-book | display set | match auditor set security address-book global address auditor-1 65.x.x.x/32 set security address-book global address auditor-2 69.x.x.x/28 set security address-book global address-set auditor address auditor-1 set security address-book global address-set auditor address auditor-2 SRX# show security address-book | display set | match auditor-rfc set security address-book global address auditor-rfc 10.132.6.128/32
SRX# run show security nat destination rule rule1 node0: -------------------------------------------------------------------------- Destination NAT rule: rule1 Rule-set: dst-nat Rule-Id : 1 Rule position : 1 From zone : untrust Destination addresses : 65.x.x.x - 65.x.x.x Destination port : 22 - 22 Action : dnat Translation hits : 11 Successful sessions : 0 Failed sessions : 11 Number of sessions : 0
SRX# show security nat proxy-arp interface reth0.22 { address { 65.x.x.x/32; } }
Do you wanna devide that 100M to 80 and 20, for traffic going out to internet or traffic coming to SRX from internet?
Ideally you dont need proxy ARP here as this segment (HE INTERNET /28 & /32 ---------------(untrust public interface)SRX) is not falling under (65.x.x.x ADMIN_DMZ) subnet.
Are you able to access 65.x.x.x from internet, like a ping or something? If so, can you share the"show security flow session destination-prefix 65.x.x.x) ? This will help us to confirm the traffic flow directions
"set security flow tcp-session no-sequence-check" will be useful for TCP, but is your traffic TCP or UDP?
Can you try "file show /var/db/idpd/sets/Recommnded.set | find "BIT-COIN-MINING"
ref: https://kb.juniper.net/InfoCenter/index?page=content&id=KB27134
Hi there,
Proxy arp is ONLY needed when you want to receive traffic for an IP which is not configured on the ingress interface but falls in the same subnet.
e.g.
Let interface address be 1.1.1.1/24 and you want to receive traffic for 1.1.1.10 . In this case, we will need a proxy-arp so that next-hop devices can forward traffic to this interface.
But if you are trying to receive a traffic for 2.2.2.10 on the interface 1.1.1.1/24 , you would NOT need proxy-arp. Rather you will need some routing protocol to export this route to your next hop so that they can forward it to you.
Coming back to your issue, I think the sessions are NOT failing due to NAT. They are failing because of the reverse route look up.
When the traffic arrives to your device on untrust interface , it is trying to access 65.x.x.x/32 which is being translated to 10.132.6.128/32.
But when the SRX looks up the return route, it would find that the 65.x.x.x subnet belongs to ADMIN_DMZ zone but the traffic originally arrived on untrust zone. This will cause the session to fail.
My potential solution will be to write a specific static route to 65.x.x.x/32 pointing towards the Internet gateway
OR
use a different IP from the subnet on the untrust interface.
Hopefully this will solve the problem.
Thanks!
AFAIK, SRX will do reverse route lookup for the source IP, which is from internet and is reachable via untrust zone only. So I belive it may not be related to return route issue. But collecting traces can confirm this
Hello Sagar,
It appears that you are getting very low throughput irrespective of VPN. You may like to check if the ISP is throttling your bandwidth or the line has any significant drops.
If you are not using routing-instances , then you can run "traceroute monitor x.x.x.x" to see the latency/drops at every hop between your VPN peers.
Thanks!
Hi rsuraj,
Many thanks
Hi all,
Thanks for all of you for responding. Sorry for late response, I had some issues with my account and I had to create an another one.
Your G/W is 10.0.0.14 and LAN is 10.2.4.0/24. When you are trying to access 172.16.1.1 SRV from 10.2.4.0/24.
Even there is NAT configuration there is no policy for 10.2.4.0/24 where it go. Try Including it in policy.
>> I think the following policy will match this criteria...
set security policies from-zone SRV to-zone UNTRUST1 policy SRV-UN1 match destination-address any
I did some config adjustments as per your advice.
There seems that nat flow sessions are OK. But, the detailed traceoptions suggest that there is no response from SRV to UNTRUST.
Regards
Hi!
I am trying to configure a static nat for my secondary assigned IPs (200.200.200.64/27) which were routed to my primary IP (200.200.200.44) by my isp.
The outbound is working but the inbound is not. I feel I must be missing something obvious but I think I opened up everything via policies and on the zones. Any help would be appreciated!
Relevant configuration sections:
nat { static { rule-set mgmt { from zone Internet; rule mgmt { match { destination-address-name 200.200.200.66; } then { static-nat { prefix { 10.20.10.66/32; } } } } } } } policies { from-zone Internet to-zone Trust { policy ALL { match { source-address any; destination-address any; application any; } then { permit; log { session-close; } } } } from-zone Trust to-zone Internet { policy All_Trust_Internet { match { source-address any; destination-address any; application any; } then { permit; } } } default-policy { deny-all; } } zones { security-zone Trust { host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { vlan.1 { host-inbound-traffic { system-services { all; } protocols { all; } } } } } security-zone Internet { host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { ge-0/0/0.0 { host-inbound-traffic { system-services { all; } protocols { all; } } } } } } } interfaces { ge-0/0/0 { unit 0 { family inet { address 200.200.200.44/29; } } } ge-0/0/2 { unit 0 { family ethernet-switching { port-mode access; vlan { members vlan1; } } } } ge-0/0/3 { unit 0 { family ethernet-switching { port-mode access; vlan { members vlan1; } } } } vlan { unit 1 { family inet { address 10.20.10.1/24; } } } } routing-options { static { route 0.0.0.0/0 next-hop 200.200.200.41; route 10.20.10.0/24 next-hop 10.20.10.1; } } vlans { vlan1 { vlan-id 3; l3-interface vlan.1; } }
Do you have an address book entry named 200.200.200.66? If not, I would suggest using 'destination-address 200.200.200.66/32' instead of destination-address-name which looks for entries in the address book.
user@fw# ... rule-set wan cso match destination-? Possible completions:> destination-address Destination address> destination-address-name Address from address book
Hello, thanks for answering, I did actually have the address in the address book but I changed it anyway and it looks like this now:
static { rule-set mgmt { from zone Internet; rule mgmt { match { destination-address 200.200.200.66/32; } then { static-nat { prefix { 10.20.10.6/32; } } } } }
Unfortunately, still not working.
Could you please share output from 'show security nat static rule all' ?
and can you confirm that you can access the internal host on the relevant port/service? Maybe just confirm that ping is working from the SRX to 10.20.10.6
Here it is:
Total static-nat rules: 1 Total referenced IPv4/IPv6 ip-prefixes: 2/0 Static NAT rule: mgmt Rule-set: mgmt Rule-Id : 1 Rule position : 1 From zone : Internet Destination addresses : 200.200.200.66 Host addresses : 10.20.10.6 Netmask : 32 Host routing-instance : N/A Translation hits : 1292 Successful sessions : 85 Failed sessions : 1207 Number of sessions : 1
Ping works from the SRX to 10.20.10.6
and 10.20.10.6 is fully accessible when connected to the dynamic VPN configured on the SRX.
Try enabling packet tracing to see where in the packet processing steps the inbound packets are being dropped. Try something like this:
set security flow traceoptions file TEST
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter TEST destination-prefix 200.200.200.0/24
Also, why do you have this static route?
route 10.20.10.0/24 next-hop 10.20.10.1;
You should have a direct route for 10.20.10/24 via vlan.1, with a better preference so it shouldn't matter, but I was curious.