Dear Rahul,
please see attachment for forwarding table.Let me know why reject of 8.8.8.8.
Dear Rahul,
please see attachment for forwarding table.Let me know why reject of 8.8.8.8.
Dear Steve and jonashauge,
Please see the attachment files. i already run nat in firewall.L3 switch didn't run nat.i run static route in l3 switch with firewall ip as next hop IP.i already allow any any to internet.i didn't put prefix or alternative one route statement per vlan beause i want to run round robin for wan loadbalance.
wrote: As Steve suspect you are missing a route for your vlan subnets.
something like 'set routing-options static route <lan-net> next-hop 10.7.1.1' where you have to either route a larger prefix or alternative one route statement per vlan.
Nat and security policies should allow traffic correctly when routes have been applied.
Hi,
Output doesn't look good.
routing-options {
static {
route 0.0.0.0/0 next-hop [ 203.118.143.129 101.177.211.65 ];
}
forwarding-table {
export LOAD_BALANCE;
}
}
policy-options {
policy-statement LOAD_BALANCE {
then {
load-balance per-packet;
}
}
}
I was expecting somthing like below.
test# run show route 8.8.8.8
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
8.8.8.8/32 *[Static/5] 4d 23:36:11
to 10.10.10.35 via reth0.0
> to 10.10.20.35 via reth2.0
test# run show route forwarding-table destination 8.8.8.8
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
8.8.8.8/32 user 0 ulst 262142 2
10.10.10.35 hold 1347 2 reth0.0
10.10.20.35 ucst 1330 3 reth2.0
Can you configure below static route and check the forwarding-table for 8.8.8.8/32?
routing-options {
static {
route 8.8.8.8/32 next-hop [ 203.118.143.129 101.177.211.65 ];
Regards,
Rahul
Hi Rahul,
it is not solution .when i plug out one wan link i can ping to 8.8.8.8 from firewall . if i put two wan link are pluged it can not ping .
but local network and local hosts can ping to 8.8.8.8.
Hi,
Yes, I need to check if forwarding-plane is correctly programmed. Can you please share the output requested.
Regards,
Rahul N
Dear All,
Please help me to solve destination nat configuration erros.I have two wan and running per-packet loadbalance (not failover).i want to access my some servers in my local network from external network . i try to configure destination nat according following links. But i cannot access.I can access my firewall wan interface from external network.i want to get remote access to my servers from externa network.how should i do? do i need following configuration in security policy.
}
from-zone untrust to-zone trust {
policy aztserveraccess {
match {
source-address any;
destination-address any;
application any;
source-identity any;
}
then {
permit {
destination-address {
drop-untranslated;
}
}
}
}
http://www.mustbegeek.com/configure-destination-nat-in-juniper-srx/
Sorry for the confusion.
NAT
You do NOT need to do NAT on the switch. We needed to confirm that your source NAT rule on the SRX would cover all subnets on your network. This is good per you attachment so no changes are needed.
Routing
Your multiple VLANs on the switch each have a ip address subnet associated with them. You need to insure that those ip subnets have a route on on the SRX pointed to the switch ip address link 10.1.7.1.
This is missing and likely the problem
On the SRX add routes for all these subnets:
set routing-options static route x.x.x.x/xx next-hop 10.1.7.1
If all the routes are continuous you can add a single larger route that covers the whole range instead of individual ones.
Do the verification commands show any sessions using nat?
show security nat destination pool all
security nat destination rule all
Does you specific inbound test create a session?
show security flow session
you can also walk throught the tests outlined here and post the results from any step you need assitance in interpreting
https://kb.juniper.net/InfoCenter/index?page=content&id=KB21839
What Junos version are you running?
I'm aware of at least two static nat bugs (call PR in Junos for problem reports).
https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1040185
Resolved In | 12.1X44-D45 12.1X46-D35 12.1X47-D20 12.3X48-D10 |
https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR834145
Resolved In | 11.4R7 12.1X44-D15 12.1X44-D20 12.1X45-D10 12.1R6 |
Thanks, I am running 15.4, the scenario described in neither PR applies to the incident we had, the cluster is strict active-standby, there is no Z-mode flow, plus the problem happened when the session was initiated from private/trust side of the security zone.
I would encourage your jTAC engineer to look for matching bugs in the PR database. Hopefully someone else has already reported this. Since your configuration is correct and the problem is intermitent this pretty much has to be a bug.
If you are the first report, then JTAC needs to gather all the data needed to reproduce it in their lab and create the new PR for the Junos software team to fix. This can be hard with an intermitent problem so push JTAC hard too.
Trying to sort through the options here, but this is the fundamental problem. The static sub interface on the dSL is up/down
at-1/0/0.0 up down inet 8x.7x.x9.x1 --> 0/0
Since this is down your public address is in reject instead of active
and your default route will not install because the interface is down.
I cannot see the error with the configuration causing the connection negociation to fail.
Can you try enabling trace options on the at interface and see what logging we get for the connection?
set interface at-1/0/0 traceoptions file dsl.log
set interface at-1/0/0 traceoptions flag all
Then show the results using:
show log dsl.log
Hi Steve and anyone else who might be interested. I have finally cracked this, here's the config. that worked for my Zen Internet (UK) ADSL connection:-
set interfaces at-1/0/0 dsl-options operating-mode auto
set interfaces at-1/0/0 encapsulation atm-pvc atm-options vpi 0
set interfaces at-1/0/0 unit 0 encapsulation atm-ppp-vc-mux vci 0.38
set interfaces at-1/0/0 unit 0 ppp-options chap local-name zen@zen
set interfaces at-1/0/0 unit 0 ppp-options chap default-chap-secret 12345678
set interfaces at-1/0/0 unit 0 ppp-options chap passive
set interfaces at-1/0/0 unit 0 family inet address 8x.7x.x9.x1/32
set routing-options static route 0.0.0.0/0 next-hop at-1/0/0.0
what about
SRX300
SRX320
SRX340
& SRX345 ?
Hello,
Is it supported now (D120) or not?
Regards,
Pawel
This is a weird one to wrap my head around so searching the forums hasnt lead to much success..
I have an SRX that is connected to a provider on a /30. I am advertising an external /24 and I NAT those externals to a dmz IP like you would imagine. Business as usual right?
Well now I have this random requirement to give another firewall one of those /24 addresses on the "outside"
My /24 doesnt have an associated interface so there isnt a gateway for this other FW to use. I suppose I would have to create a new interface on the SRX to make this happen but surely somebody else has fought this same fight already.
Short version I need to insert this new FW between the SRX's router and FW and I dont really know where to start.
Glad you have it working. Thanks for posting the configuration.
I do understand the situation pefectly. Any way you do this the only path to your upstream is that /30 on your SRX. So there is no "putting another firewall in front of the existing one". Ultimately the path out to the carrier is the SRX interface.
I would start by asking your carrier if you can change from a /30 to a /29 on this service. That is the straight forward and simple path for this request.
If you do have to do configuration gymnastics instead, this is one method with the existing setup.
Create a new interface on the SRX with the subnet in the /24 for the new firewall untrust port.
This is the default gateway for the new firewall and the address for it.
This will need to have enough addresses for whatever nat is needed on the new device.
Put this interface into a new zone
create allow all rules in both directions from and to this zone to the untrust so that all traffic is controled by the new firewall.
Thank you for all of your invaluable help Steve, I really appreciate it.