Hello Andrew,
The answer is yes. SRX can be used as NTP server as long as it is receiving the NTP sync from an external server.
I notice your mention of firewall filters. Note that anything which is NOT explicitly allowed in a firewall filter will be denied by the them.
It would help if you share your configuration.
Thanks!
Hello,
Just for info.
I found that You cannot ssh into an interface which belongs to a logical system. You have to ssh to an interface that belongs to the master logical system (the default one, like if you don't have any logical system at all) and the it will redirect you (based on the right of the user that you have configured) into the specific logical system.
So that's it. It is diferent from a device to another and from a software version to another.
Anyway. Thank you for taking the time.
That was a perfect breakdown and helped immensely, thank you.
syslog on Junos can only be sent via udp - you are not the first one asking that question :-)
The security logs (logs generated by the flow module on SRX) can be sent via tcp but it is only logs related to security policies, vpn etc. which are sent this way. The ordinary syslog in regards to eg. user login, interface up/down etc. can only be exported via udp.
I have not heard about any roadmap to change this.
Dear All,
I am beginner in Juniper product.
I would like to request to help and find out my network problem.
I have one server and one NAS and network connectivity as below design.I am using cisco switch,juniper srx and junos e4300 switches.
My first question is my design is correct or not ?
Can i carry firewall traffic with access port ( VLAN 10 ) in cisco switch ?
OR do i need to create trunk and etherchannel in cisco switch also ?
I already run etherchannel in Junos E4300 (ae0,ae1) .
I already traffic server to NAS. what kind of configuration do i need to access server to NAS ?
Ok, its the security logs I am after and even though I have specified them to be sent over TCP they still appear to be using UDP, is there a way to get the SRX to acknowledge the config and send the security logs over TCP?
Hi,
Access vlan "VLAN10" are on the cisco and is not transmitted towards SRX.(no tag)
Since traffic will be un-tagged and hence reth0.0 should accept the same.
Regards,
Rahul
your configuration for stream logging looks correct. Have you tried enabling traceoptions (debug) to pinpoint potential issues?
set security log traceoptions file stream-debug
set security log traceoptions flag all
Also remember that stream logs are sent by the PFE, not the RE - so the log collector has to be reachable via a revenue port. And source-address should also be on the PFE (not a management interface).
I just tried creating a stream where the receiving host does not answer on port 514 which gives a clear error:
user@fw> show log stream-debug | match SYN
May 15 08:24:40 rtlogd: miscellaneous string(len=107)=Connection error flaf Error code: major 3 minor 1 code 110, description:TCP time out after SYN is sent out
Let us know if this makes you able to get your tcp logging working as expected.
Thanks for the replies, Disciple and Jonas
I'm limited on what config I can supply because of the nature of the account I work on, so before I work out what I can post, can I just check one thing with you both? Specifically I want to use a loopback as the NTP server address on the SRX. Is that possible? None of the relevant posts and articales I have read have mentioned loopbacks, and even your config, Jonas, shows a physical interface being used.
I'm pretty sure I have all the recommnended config in place, but of course I may be a bit config-blind by now, so if you could you confirm whether or not there's any reason why the recommended config shouldn't work with a loopack interface on the SRX, or anything additional I might have to do to make it work, that would be great.
Thank
Loopback address can be configured as NTP server address and it should work as expected. You may check without firewall filter and do monitor traffic to verify NTP traffic
To answer your queries:
1. I dont see any issue with your design.
2. There is no need to configure between Cisco and SRX as you have only one vlan traffic.
3. You have to configure security policies to allow the traffic between Server and NAS
Hello there,
Here are my thoughts on your setup: -
1. The first question is whether your design is correct or not.
=> Although it looks okay to me but I am wondering how are you connecting the NAS server to the virtual chassis. I see two links coming out of NAS. Does your NAS server has 2 NIC cards with same IP address ?
2. Can I carry the firewall traffic with access port on cisco switch?
=> Is your reth0 interface tagged with any vlan-id? If yes, then the CISCO port facing SRX will need to be trunk otherwise access is fine. In either case, CISCO port facing 10.1.1.3 can still be access without any problem.
3. what kind of configuration do i need to access server to NAS ?
=> Assuming that you are trying to access NAS server from 10.1.1.3 device. You would need the following: -
A. 10.1.1.3 should have a route to 10.1.2.2 pointing towards 10.1.1.1.
B. 10.1.2.2 should have a route to 10.1.1.3 poiting towards 10.1.2.1.
C. Config on SRX: -
i) SRX needs to have a security policy to allow traffic between zone of reth0 towards zone of reth1. Based on what protocol you are using to access the NAS (lets assume for now its SMB), then your policy would need "junos-smb/ junos-smb-session" applications to be allowed. You can also customize the application as per your need.
ii) You may need to have a policy in the reverse direction if you expect sessions to start from NAS towards the 10.1.1.3 too.
iii) Since reth1 has 2 links to each node, I will also advice you run LACP on reth1 and connected virtual chassis. [NOT MANDATORY]
iv) Also , try to configure both reth0 and reth1 in the same redundancy-groups to ensure that the file transfers avoid crossing fabric links on the SRX. Crossing fabric links generally slows down throughput. [NOT MANDATORY]
Hope this helps.
Thanks and Good Luck!
Hello experts,
Please respond.
=> fatls usb 1:1
system volume information/
149518174 junos-srxsme-12.1x46-d86-domestic.tgz
4096 ._junos-srxsme-12.1x46-d86-domestic.tgz
.fseventsd/
639364 uboot
4096 ._uboot
297184 loader_crc
4096 ._loader_crc
4096 ._.trashes
.trashes/
.spotlight-v100/
7 file(s), 4 dir(s)
=>
Followed:
fatload usb 1:1 0x100000 uboot
bootloader upgrade u-boot active 0x100000
reset
fatload usb 1:1 0x100000 loader_crc
bootloader upgrade loader 0x100000
Reset
Still stuck on this prompt. any thought please?
Hi Andrew,
Do you have a firewall filter configured on the loopback?
Please check below KB article. If you do have filters you might have to modify them to include the loopback IP.
https://kb.juniper.net/InfoCenter/index?page=content&id=KB11436
Anand
Hi rschwarz,
Are you using NMAP for port scanning?
If so please check: https://kb.juniper.net/KB32646
Anand
Hello Andrew,
I tested a basic setup as shown below. I needed an intrazone policy to get this to work. Perhaps in your case you may need an inter-zone policy permitting ntp depending on your setup.
Topology:
SRX1 (NTP Client) ge-0/0/0.0 ----- ge-0/0/0.0 SRX2 (NTP Server) (lo0.0 - 192.168.50.1)
NTP Client config:
set system ntp server 192.168.50.1
set interfaces ge-0/0/0 unit 0 family inet address 192.168.10.2/24
set routing-options static route 192.168.50.1/32 next-hop 192.168.10.1
NTP Server config:
set interfaces ge-0/0/0 unit 0 family inet address 192.168.10.1/24
set interfaces lo0 unit 0 family inet address 192.168.50.1/32 << No interface filter
set security zones security-zone trust host-inbound-traffic system-services all <<< I think you have ntp specifically allowed here
set security zones security-zone trust interfaces ge-0/0/0.0
set security zones security-zone trust interfaces lo0.0
Intra-zone policy to allow ntp:
set security policies from-zone trust to-zone trust policy allow-ping-ntp match source-address any
set security policies from-zone trust to-zone trust policy allow-ping-ntp match destination-address any
set security policies from-zone trust to-zone trust policy allow-ping-ntp match application junos-ping
set security policies from-zone trust to-zone trust policy allow-ping-ntp match application junos-ntp
set security policies from-zone trust to-zone trust policy allow-ping-ntp then permit
Result:
root@vsrx# run show ntp associations
remote refid st t when poll reach delay offset jitter
===============================================================================
192.168.50.1 X.X.X.X 4 - 1 64 1 1.976 0.301 0.112
I hope this helps. Regards,
Vikas
Hi,
QUE :- What's the default value being used as tcp-mss on ipsec?
Juniper:- There is no default value that is defined explicitky for IPSEC traffic. It uses the ethernet default set.
QUE:- and how to view the default value?
Juniper:- NA
Moreover what's the juniper recommended tcp-mss value ?
Juniper :- Juniper cannot explicitly define one tcp-mss value for IPSEC as the value is dependent upon network to network.
What's the afect of mss Inreasing or decreasing ?
Juniper :- This is a Gud Que
For Example :- MTU of the egress interface is 1500.
Generic defination for MSS for generic traffic is 1500 - (TCP+IP header)
Likewise for IPSEC it would be 1500 - (TCP+IP +ESP)
Further, decreasing MSS to very low lets say 1000 would result into more no of packets being generated by the source. Hence Overhead.
increasing the MSS to lets say 1460 for ESP traffic would mean ESP packets being fragmented. Hence Overhead.
Regards,
Rahul
Hello,
Looking at the problem symptom and the troubleshooting done with respect to TCP-MSS it is clear that the problem is not with fragmentation.
It is indeed strange, why the application would behave differently with or without ping to it. A packet capture from client and server side with and without ping would be ideal to troubleshoot the problem. I do not believe given the symptoms, that this is an issue with the firewall/vpn setup.
I am assuming this is the only application impacted.
Regards,
Vikas
Hi,
Further to talk about your issue:-
1. User sends continous ping to the destination APP host and then the APP works fine.
Juniper :- This is wiered, You mention every location to see similar state. Kindly confirm if we see similar issue with the APP host without accessing the same via VPN?
2. SRX300 is on the branch side.
Juniper:- Do we have SRX on the hub site too ? Since traffic for the APP would be from APP host side towards the branch, hence if this has any thing to do with fragmentation it would be on the hub side.
Regards,
Rahul
Juniper