Dear Team ;
I have SRX320 with LTE Card .
i have inserted two sim cards from two different ISP .
Two Sim cards are for Private VPN (to reach HQ).
Is it possible to establish one gre tunnel on each SIM Card to act as Active-Passive solution ??
Will the two gre tunnels be up all the time ??
What is the right approach to configuring this when Source NAT is desired (assuming bandwidth available is sufficient) ?
For example, consider an SRX-300 where Organization A is on ge-0/0/0.0 with interface address 10.0.1.1/24, Organization B is on ge-0/0/3.0 with interface 192.168.100.1/24, and the uplink to the ISP is ge-0/0/5.0 using DHCP Client. For each of A and B, it is desired to use the JDHCP server in the SRX to allocate addresses to client systems belonging to A and separately to allocate addresses to client systems belonging to B. The SRX is running JunOS 17.4, by the way.
I tried creating 3 security zones (one each for A, B, and ISP), using only the default routing instance, defining separate address pools for A and B, and with source-nat security policies for each security zone in (A, B) to the ISP security zone (and corresponding deny security policies for traffic being initiated outside and arriving on the ISP interface), but this did not work. It was not able to get the JDHCP server to provide addresses from ge-0/0/3.0 to systems in Organization B attached to that subnet and interface. I can get this to all work if I only have organization A and the ISP, but no 2nd organization on a separate SRX interface.
-- Should I create separate routing instances for A and B ?
-- What is the correct configuration strategy for this scenario ?
You should be able to configure dhcp server for both segments. Are you using the new version configuration under system services dhcp-local-server?
You can enable trace options and post the configuration for review.
Your setup should work with blocking traffic between the zones. Routing instances would provide a more robust separation as the two sites would not even have routes to reach each other. But either will work and would have nothing to do with the dhcp not working.
An important thing to remember about intrazone traffic is for devices in the same subnet. Typically the SRX has the gateway address so it is always in the path of traffic when you leave the zone.
But if two devices are in the same subnet broadcast domain.
Connected to a switch downstream of the SRX
The traffic between these two devices will never be seen by the SRX or any policy between them enforced.
Since they are in the same broadcast domain on a switch they can talk to each other regardless of any SRX intrazone policy.
Hello,
Since at point of time only single profile can be active, I doubt if you can have both GRE up at the same time ever if you are able to configure it.
Regards,
Rushi
wrote: Hi,
SRX will not reply to the arp requests if the request is not in the same subnet range. In this case, srx subnet is 172.20.15.0/24 and the arp request is coming from different subnet 73.x.x.x. Try to add static arp entry for 172.20.15.172 in DSL modem, if possible.
If you are correct, then maybe I'm reading the instructions wrong? Following this (https://kb.juniper.net/InfoCenter/index?page=content&id=KB21611&actp=METADATA) troubleshooting guide, it clearly shows that the nat pool needs to be in the same subnet as the external SRX interface.
3. Is the NAT pool from the same subnet as the SRX external interface? (For example, if the NAT pool is 1.1.1.2 thru 1.1.1.4, and the SRX external IP address is 1.1.1.1/24, then the NAT pool is on the same subnet as the SRX external IP address.)
4. Run the configuration command: show security nat proxy-arp
Is Proxy ARP configured for the NAT pool IP addresses? For more information on Proxy ARP and how to configure it; go to KB21785 - [SRX] When and how to configure Proxy ARP.
Follwing the link for how to configure Proxy ARP it states:
As specified in Configuring Proxy ARP (CLI Procedure), Proxy ARP should be configured for the following scenarios:
- When addresses defined in the static NAT and source NAT pool are in the same subnet as that of the ingress interface (Source NAT and Static NAT scenario)
What you seem to be saying is that I need to configure this for the outside, public, IP space not the subnet that the ingress (for return packets) interface's subnet.
Also, in the original post, the arp requests were hitting the ingress interface saying where is the 172.20.15.172/32. Since the interface is in the 172.20.15.0/24 subnet, shouldn't it answer?
I must be reading something wrong so I appreciate if you could point it out.
wrote: can you configure ip 172.20.15.172 on lo0.0 interface and check if you can ping any address on the wan with src 172.20.15.172 ?
I tried to configure a loopback interface as suggested:
set interfaces lo0 unit 0 description "Loopback for testing NAT issue using 172.20.15.x as NAT pool"
set interfaces lo0 unit 0 family inet address 172.20.15.172/24
I then initiated a ping to the outside:
root@GreatGazoo> ping verbose inet 23.216.159.40 source 172.20.15.172 record-route no-resolve
PING 23.216.159.40 (23.216.159.40): 56 data bytes
While monitoring the WAN facing interface (ge-0/0/0):
root@GreatGazoo> monitor traffic interface ge-0/0/0 no-resolve matching "src 172.20.15.172"
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on ge-0/0/0, capture size 96 bytes
19:56:55.594415 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]
19:56:56.597524 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]
19:56:57.599450 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]
19:56:58.603074 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]
19:56:59.604790 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]
19:57:00.606073 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]
19:57:01.607512 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]
19:57:02.609225 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]
19:57:03.610746 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]
19:57:04.616081 Out IP truncated-ip - 64 bytes missing! 172.20.15.172 > 23.216.159.40: [|icmp]
Clearly the echo request was getting out of the interface (or at least to the point where monitor traffic saw it) but there appears to be not attempt at reply. I'm guessing I may have something else that isn't setup properly? There should not be any firewall filters in between as there are only input filters on ge-0/0/0 and did not see any deny messages.
I don't have any routing instances set up but maybe I need to add a security policy to allow the 172.20.15.x out? Since I'm pinging from an inside interface (lo0) that isn't included in any zone, could that be why it's appearing to not leave?
Dear Juniper
Can i use DAC cable 10GB for Chassis cluster (Control and fabric)?
Hi,
Your configuration is correct. But you are getting the arp request from the modem's WAN ip address. It should be from the LAN address of the modem, like below:
18:08:59.573682 In arp who-has 172.20.15.172 tell 172.20.15.254
Hi Priyavit,
As per the Juniper documentation you can use the following DAC SFPs in SRX4100 and SRX4200:
SRX-SFP-10GE-DAC-1M
SRX-SFP-10GE-DAC-3M
SRX4100:
https://apps.juniper.net/hct/product/#prd=SRX4100
SRX4200:
https://apps.juniper.net/hct/product/#prd=SRX4200
I hope this info is hepful.
Hi Alfonso,
ARP is intended for resolving the MAC addresses of devices within the same L2 domain (same subnet). In this case the modem should only send an ARP request towards the SRX if the destination address of the reply packet (172.20.15.172) is within the same subnet of one of its local interfaces (172.20.15.1). In our case, this is true, however the ARP request sent to the SRX should be sourced from an IP address on that subnet (172.20.15.0/24) and as you can see the arp request is sourced from an address of a different subnet:
root@GreatGazoo> monitor traffic interface ge-0/0/0 no-resolve no-domain-names verbose output suppressed, use or for full protocol decode Address resolution is OFF. Listening on ge-0/0/0, capture size 96 bytes 18:08:59.573682 In arp who-has 172.20.15.172 tell 73.xx.xx.x7 18:09:18.483741 In arp who-has 172.20.15.172 tell 73.xx.xx.x7 18:09:39.737295 In arp who-has 172.20.15.172 tell 73.xx.xx.x7
I will engage the modem provider to verify this odd behavior. Also go ahead and disconnect/connect this connection and see if the ARP works fine after that. Also you can reboot the modem, this often resolves this weird behaviors.
If the problem remains, you will have to insert a static route in the modem to point to 172.20.15.254 whenever the modem wants to send packets to 172.20.15.172.
I hope this info helps.
I am sure Juniper and Pulse are doing everything possible to fix this situation because as you said, you are not the only one with this problem. Check, from time to time, the TSB document that I previously provided, it will be updated when the solution is delivered.
I hope this info was helpful, please mark it as Resolved if it applies.
Hello all,
I am currently trying to have two of my zones communicate with the Internet (untrust zone) without success. I have other zones that work fine. Machines can also communicate from one zone to another without issues.
Unfortunately I've inherited the current configuration with little explanations, and I'm no network expert to start with, so I'm a bit at a loss currently. I did try to troubleshoot but there are many things I don't really understand.
My zones use the 192.168.5.X and the 192.168.6.X prefixes. Zones are called PRA-MF and DMZ-PRA-MF. Here is the current configuration (all information unrelated to my issue have been removed as well as public IP addresses) :
#show interfaces
reth0 {
description "VLANS PRODUCTION";
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
}
unit 300 {
description "VLAN PRA-MF";
vlan-id 300;
family inet {
address 192.168.5.254/24;
}
}
unit 301 {
description "VLAN DMZ-PRA-MF";
vlan-id 301;
family inet {
address 192.168.6.254/24;
}
}
}
reth2 {
redundant-ether-options {
redundancy-group 1;
}
unit 0 {
family inet {
filter {
input mf-pra;
}
address XXX.XXX.XXX.XXX {
preferred;
}
}
}
}
#show security zones security zone PRA-MF
host-inbound-traffic {
system-services {
ping;
telnet;
}
}
interfaces {
reth0.300 {
host-inbound-traffic {
system-services {
ping;
telnet;
}
}
}
}
#show security zones security zones DMZ-PRA-MF
address-book {
address 192.168.6.50 192.168.6.50/32;
address-set set1 {
address 192.168.6.50;
}
}
host-inbound-traffic {
system-services {
ping;
telnet;
}
}
interfaces {
reth0.301 {
host-inbound-traffic {
system-services {
ping;
telnet;
}
}
}
}
#show security zones security zone untrust
host-inbound-traffic {
system-services {
ike;
http;
https;
ping;
ssh;
}
}
interfaces {
reth2.0 {
host-inbound-traffic {
system-services {
ike;
ssh;
https;
ping;
http;
}
}
}
}
#show security policies
from-zone PRA-MF to-zone DMZ-PRA-MF {
policy flux_DMZ-PRA-MF {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone DMZ-PRA-MF to-zone PRA-MF {
policy flux_PRA-MF {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone PRA-MF to-zone untrust {
policy flux_untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone PRA-MF {
policy flux_untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone DMZ-PRA-MF to-zone untrust {
policy flux_untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone DMZ-PRA-MF {
policy flux_untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
#show firewall filter mf-pra
show firewall filter matignon-pra
term 1 {
from {
destination-address {
XXX.XXX.XXX.XXX/XXX;
}
destination-port [ 6330 1763 6331 22 5822 6537 990 4822 ];
}
then {
routing-instance PRA-MF;
}
}
term 2 {
then accept;
}
#show routing-options
static {
route 192.168.6.50/32 next-table PRA-MF.inet.0;
route 192.168.5.50/32 next-table PRA-MF.inet.0;
route 192.168.5.51/32 next-table PRA-MF.inet.0;
route 192.168.5.52/32 next-table PRA-MF.inet.0;
route 192.168.5.53/32 next-table PRA-MF.inet.0;
route 192.168.5.54/32 next-table PRA-MF.inet.0;
route 192.168.5.55/32 next-table PRA-MF.inet.0;
route 0.0.0.0/0 next-hop XXX.XXX.XXX.XXX;
}
instance-import route-import-XXX-XXX-XXX;
#show routing-instances
PRA-MF {
description "PRA MATIGNON FINANCES";
instance-type virtual-router;
interface reth0.300;
interface reth0.301;
routing-options {
static {
route 0.0.0.0/0 next-hop XXX.XXX.XXX.XXX/XXX;
}
instance-import TO-PRA;
}
}
#show policy-options policy-statement TO-PRA
term 1 {
from {
instance master;
protocol direct;
route-filter YYY.YYY.YYY.YYY/YYY exact; ##this is an old public IP address no longer in use
}
then accept;
}
term 2 {
then reject;
}
#show security nat source
rule-set trust-to-untrust3 {
from zone [ DMZ-PRA-MF PRA-MF ];
to zone untrust;
rule source-nat-rule3 {
match {
source-address 0.0.0.0/0;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
rule-set PRA-MF-to-reth2 {
from routing-instance PRA-MF;
to interface reth2.0;
rule source-nat-PRA {
match {
source-address 0.0.0.0/0;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
#show security nat destination
pool DMZ-PRA-MF {
address 192.168.6.50/32;
}
rule-set untrust {
rule DMZ-PRA-MF-1763 {
match {
destination-address XXX.XXX.XXX.XXX/XXX;
destination-port 1763;
}
then {
destination-nat {
pool {
DMZ-PRA-MF;
}
}
}
}
rule DMZ-PRA-MF-6331 {
match {
destination-address XXX.XXX.XXX.XXX/XXX;
destination-port 6331;
}
then {
destination-nat {
pool {
DMZ-PRA-MF;
}
}
}
}
rule DMZ-PRA-MF-6537 {
match {
destination-address XXX.XXX.XXX.XXX/XXX;
destination-port 6537;
}
then {
destination-nat {
pool {
DMZ-PRA-MF;
}
}
}
}
rule DMZ-PRA-MF-5822 {
match {
destination-address XXX.XXX.XXX.XXX/XXX;
destination-port 5822;
}
then {
destination-nat {
pool {
DMZ-PRA-MF;
}
}
}
}
rule DMZ-PRA-MF-4822 {
match {
destination-address XXX.XXX.XXX.XXX/XXX;
destination-port 4822;
}
then {
destination-nat {
pool {
DMZ-PRA-MF;
}
}
}
}
rule DMZ-PRA-MF-990 {
match {
destination-address XXX.XXX.XXX.XXX/XXX;
destination-port 990;
}
then {
destination-nat {
pool {
DMZ-PRA-MF;
}
}
}
}
rule DMZ-PRA-MF-22 {
match {
destination-address XXX.XXX.XXX.XXX/XXX;
destination-port 22;
}
then {
destination-nat {
pool {
DMZ-PRA-MF;
}
}
}
}
}
I've also made traceoptions for the issue with the basic-datapath flag. Tried pinging the Google DNS server (8.8.8.8) from a machine that has the IP 192.168.5.52, and here are the results :
Oct 16 10:33:25 10:33:25.555056:CID-1:RT:<192.168.5.52/2525->8.8.8.8/1;1> matched filter MatchPRA:
Oct 16 10:33:25 10:33:25.555094:CID-1:RT
acket [60] ipid = 11491, @0x422bff24
Oct 16 10:33:25 10:33:25.555094:CID-1:RT:---- flow_process_pkt: (thd 3): flow_ctxt type 15, common flag 0x0, mbuf 0x422bfd00, rtbl_idx = 5
Oct 16 10:33:25 10:33:25.555132:CID-1:RT: flow process pak fast ifl 78 in_ifp reth0.300
Oct 16 10:33:25 10:33:25.555132:CID-1:RT: reth0.300:192.168.5.52->8.8.8.8, icmp, (8/0)
Oct 16 10:33:25 10:33:25.555158:CID-1:RT: find flow: table 0x491f8d40, hash 45441(0xffff), sa 192.168.5.52, da 8.8.8.8, sp 2525, dp 1, proto 1, tok 20499
Oct 16 10:33:25 10:33:25.555158:CID-1:RT: no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0
Oct 16 10:33:25 10:33:25.555158:CID-1:RT:search gate for PRA-MF:192.168.5.52/2525->8.8.8.8/1,1
Oct 16 10:33:25 10:33:25.555158:CID-1:RT:gate_search_specific_bucket: no gate found
Oct 16 10:33:25 10:33:25.555158:CID-1:RT:search widecast gate for PRA-MF:192.168.5.52/2525->8.8.8.8/1,1
Oct 16 10:33:25 10:33:25.555158:CID-1:RT:gate_search_widecast_bucket: no gate found
Oct 16 10:33:25 10:33:25.555158:CID-1:RT: flow_first_create_session
Oct 16 10:33:25 10:33:25.555158:CID-1:RT:First path alloc and instl pending session, natp=0x4cd13980, id=47766
Oct 16 10:33:25 10:33:25.555158:CID-1:RT: flow_first_in_dst_nat: in <reth0.300>, out <N/A> dst_adr 8.8.8.8, sp 2525, dp 1
Oct 16 10:33:25 10:33:25.555158:CID-1:RT: chose interface reth0.300 as incoming nat if.
Oct 16 10:33:25 10:33:25.555360:CID-1:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 8.8.8.8(1)
Oct 16 10:33:25 10:33:25.555360:CID-1:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 192.168.5.52, x_dst_ip 8.8.8.8, in ifp reth0.300, out ifp N/A sp 2525, dp 1, ip_proto 1, tos 0
Oct 16 10:33:25 10:33:25.555405:CID-1:RT
oing DESTINATION addr route-lookup
Oct 16 10:33:25 10:33:25.555422:CID-1:RT:Route-lookup for 8.8.8.8 yielded reject NH
Oct 16 10:33:25 10:33:25.555422:CID-1:RT: packet dropped, no route to dest
Oct 16 10:33:25 10:33:25.555422:CID-1:RT:flow_first_routing: DEST route-lookup failed, dropping pkt and not creating session nh: 4294967295
Oct 16 10:33:25 10:33:25.555422:CID-1:RT: packet dropped, ROUTE_REJECT_GEN_ICMP.
Oct 16 10:33:25 10:33:25.555465:CID-1:RT:flow send icmp: pak->natp=0x4cd13980, pak->nsp=0x4cd13980
Oct 16 10:33:25 10:33:25.555465:CID-1:RT:Embedded ICMP outer iphdr before xlate: c0a805fe/768 -> c0a80534/42915
Oct 16 10:33:25 10:33:25.555465:CID-1:RT:Embedded ICMP inner iphdr before xlate: c0a80534/2048 -> 08080808/17278
Oct 16 10:33:25 10:33:25.555558:CID-1:RT:flow_handle_icmp_xlate
Oct 16 10:33:25 10:33:25.555558:CID-1:RT:xlate_icmp_pak
Oct 16 10:33:25 10:33:25.555558:CID-1:RT:xlate_icmp_pak handle icmp4 embeded ip
Oct 16 10:33:25 10:33:25.555558:CID-1:RT:Embedded ICMP outer iphdr after xlate: c0a805fe/768 -> c0a80534/42915
Oct 16 10:33:25 10:33:25.555558:CID-1:RT:Embedded ICMP inner iphdr after xlate: c0a80534/2048 -> 08080808/17278
Oct 16 10:33:25 10:33:25.555558:CID-1:RT
ending icmp:3, code: 0
Oct 16 10:33:25 10:33:25.555558:CID-1:RT:flow_send_return_pak: lpak 0x48ae9eb0, npak 0x48df912c, npak->in_if N/A, outifp reth0.300.
Oct 16 10:33:25 10:33:25.555664:CID-1:RT:**** jump to packet:192.168.5.254->192.168.5.52
Oct 16 10:33:25 10:33:25.555685:CID-1:RT:skip pre-frag: is_tunnel_if- 0, is_if_mtu_configured- 0
Oct 16 10:33:25 10:33:25.555685:CID-1:RT: encap vector
Oct 16 10:33:25 10:33:25.555685:CID-1:RT: no more encapping needed
Oct 16 10:33:25 10:33:25.555685:CID-1:RT: **** pak processing end.
Oct 16 10:33:25 10:33:25.555685:CID-1:RT:flow_send_return_pak: outifp reth0.300, iif 0, vr_id 5.
Oct 16 10:33:25 10:33:25.555685:CID-1:RT:flow_send_return_pak : Using iif 0
Oct 16 10:33:25 10:33:25.555685:CID-1:RT:flow_send_return_pak() 0x43036280 : mbuf injected, return code 0
Oct 16 10:33:25 10:33:25.555685:CID-1:RT:flow_first_routing: Sending icmp/tcp-rst for route-lookup failure
Oct 16 10:33:25 10:33:25.555685:CID-1:RT:flow_initiate_first_path: first pak no session
Oct 16 10:33:25 10:33:25.555764:CID-1:RT: flow find session returns error.
Oct 16 10:33:25 10:33:25.555764:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)
Thanks in advance to anyone who might try to help.
HI !
there is a default route missing pointing to the internet
see:
Oct 16 10:33:25 10:33:25.555405:CID-1:RT
oing DESTINATION addr route-lookup
Oct 16 10:33:25 10:33:25.555422:CID-1:RT:Route-lookup for 8.8.8.8 yielded reject NH
Oct 16 10:33:25 10:33:25.555422:CID-1:RT: packet dropped, no route to dest
Oct 16 10:33:25 10:33:25.555422:CID-1:RT:flow_first_routing: DEST route-lookup failed, dropping pkt and not creating session nh: 4294967295
regards
alexander
Hello Alexander,
Thank you for your answer. As shown in my mail the routing configuration is as follow:
#show routing-options
static {
route 192.168.6.50/32 next-table PRA-MF.inet.0;
route 192.168.5.50/32 next-table PRA-MF.inet.0;
route 192.168.5.51/32 next-table PRA-MF.inet.0;
route 192.168.5.52/32 next-table PRA-MF.inet.0;
route 192.168.5.53/32 next-table PRA-MF.inet.0;
route 192.168.5.54/32 next-table PRA-MF.inet.0;
route 192.168.5.55/32 next-table PRA-MF.inet.0;
route 0.0.0.0/0 next-hop XXX.XXX.XXX.XXX; #This is the route to the internet
}
instance-import route-import-XXX-XXX-XXX;
#show routing-instances
PRA-MF {
description "PRA MATIGNON FINANCES";
instance-type virtual-router;
interface reth0.300;
interface reth0.301;
routing-options {
static {
route 0.0.0.0/0 next-hop XXX.XXX.XXX.XXX/XXX; #this is also the route to the internet, same as above
}
instance-import TO-PRA;
}
}
Do you have any idea what might be wrong with it?
do a show route table <instance-name>.inet0 0.0.0.0/0 extensive for the default route, to see if it is active and working, and if not what is the reason for it.
also look for the next-hop in the default route . Is it on a directly connected network, if not you need to add the resolve keyword to the static route definition.
as you still need the next-hop address in the routing table you should update the following with the new and correct next-hop address.
#show policy-options policy-statement TO-PRA
term 1 {
from {
instance master;
protocol direct;
route-filter YYY.YYY.YYY.YYY/YYY exact; ##this is an old public IP address no longer in use
}
then accept;
}
term 2 {
then reject;
}
regards
alexander
Hello Alexander,
Thank you once again for your reply. Here are the results of the command :
192.168.5.0/24 (1 entry, 0 announced)
*Direct Preference: 0
Next hop type: Interface
Address: 0x15a09dc
Next-hop reference count: 1
Next hop: via reth0.300, selected
State: <Active Int>
Age: 12w5d 20:54:31
Task: IF
AS path: I
192.168.5.254/32 (1 entry, 0 announced)
*Local Preference: 0
Next hop type: Local
Address: 0x1174324
Next-hop reference count: 24
Next hop:
Interface: reth0.300
State: <Active NoReadvrt Int>
Age: 12w5d 20:54:31
Task: IF
AS path: I
192.168.6.0/24 (1 entry, 0 announced)
*Direct Preference: 0
Next hop type: Interface
Address: 0x15a0990
Next-hop reference count: 1
Next hop: via reth0.301, selected
State: <Active Int>
Age: 12w5d 20:54:31
Task: IF
AS path: I
192.168.6.254/32 (1 entry, 0 announced)
*Local Preference: 0
Next hop type: Local
Address: 0x1174324
Next-hop reference count: 24
Next hop:
Interface: reth0.301
State: <Active NoReadvrt Int>
Age: 12w5d 20:54:31
Task: IF
AS path: I
Am I right to suppose that the mistake comes from the part in bold (no hop addresses)? Those addresses (5.254 & 6.254) are the interfaces addresses for the two problematic zones.
Hi all,
We're having an issue with our dynamic VPN secondary DNS allocation to clients.
The configuration is as follows :
family inet {
network 192.168.10.0/24;
range range-XXX{
low 192.168.10.200;
high 192.168.10.205;
}
xauth-attributes {
primary-dns 192.168.0.100/32;
secondary-dns 192.168.5.52/32;
}
}
However, when a client connect, only the primary DNS is attributed. Secondary DNS is ignored. This happens on both Windows 7 & Windows 10 clients.
Any help on this issue would be hugely appreciated.
Good day,
We have recently replaced a FortiGate firewall with a new Juniper SRX345. Networking-wise everything is working fine, however we are getting issues with e VPN connection to a Cisco SA520W. The VPN was working fine on the FortiGate, and no changes were made at the Cisco end. The configuration is attached.
We see the tunnels coming up, however we cannot reach the remote subnet. We also notice there are multiple IKE tunnels, where there should only be one. The tunnels sometimes keep adding up. Output attached.
We have also attached the logs. Any help/input would be appreciated. Thanks.
Hi ea-aua,
Can you hardcode the source and destination IP addresses that will be used by VPN monitoring:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB10119
Make sure they are within the subnets that are allowed to transmit traffic over the VPN: 192.168.1.0/24 and 192.168.7.0/24. You can use something like this:
set security ipsec vpn ike-vpn-BON vpn-monitor destination-ip 192.168.7.254 source-interface irb.2 optimizedI am assuming that 192.168.7.254 is an IP address on an interfaces of the ASA. If the problem is still happening, try to disable VPN-monitoring on the SRX for testing purposes.
I will also highly suggest to configure you VPN using traffic-selectors on the SRX side and match them with the ASA ACLs:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB28820