SRX

Getting to the point where I know enough to get myself into trouble 🙂 So what I'm trying to figure out now is VLAN setup. I've been reading here and the KB section for a few hours on setting them up and I keep seeing two seemingly different approaches.

One is adding a vlan member to a physical interface and then creating a vlan interface.

The other is using sub-interfaces on the physical interface.

So what's the basic difference - pros vs cons - and given I'm probably going to only have 3-4 vlans and each on it's own port of an SRX210, does that make a difference?

What I'm looking at so far for configuration:

  set interfaces ge-0/0/1 description "SRX-210 (ge-0/0/1) to TP-LINK port 1 : Gateway for HOME_LAN"
  set interfaces ge-0/0/1 gigether-options auto-negotiation
  set interfaces ge-0/0/1 unit 0 family inet address 10.20.15.254/24

  set interfaces fe-0/0/6 description "SRX-210 (fe-0/0/6) to ESXi eth2: Gateway for LAB_WORK"
  set interfaces fe-0/0/6 fastether-options auto-negotiation
  set interfaces fe-0/0/6 unit 0 family inet address 10.1.69.254/24
(or would it be unit 169??)

  set interfaces fe-0/0/7 description "SRX-210 (fe-0/0/7) to ESXi eth3: Gateway for LAB_VULN"
  set interfaces fe-0/0/7 fastether-options auto-negotiation
  set interfaces fe-0/0/7 unit 0 family inet address 10.16.36.254/24

   set vlans VLAN_LAB_WORK vlan-id 169
   set vlans VLAN_HOME_LAN vlan-id 10
   set vlans VLAN_INTERNET vlan-id 172
   set vlans VLAN_LAB_VULN vlan-id 1636

Yes I know this configuration won't work but that's all I have right now until I figure out the answer to the sub-interface vs vlan interface question.

Thanks for any suggestions/advice!!!

Hi,

What do I understand that you want to know what is the difference in creating a vlan interface and subinterface without vlan ?

Sorry for the confusion adwivedl. What I'm finding in researching is you can either config as:

Specify a new VLAN, which will be used for switching, in this case vlan 100:
user@host# set vlans vlan-100 vlan-id 100

Assign this VLAN interface as your Layer3 Interface on this VLAN:
user@host# set vlans vlan-100 l3-interface vlan.100

Configure a VLAN interface with an IP for this VLAN.   (It must be on a different L3 subnet than the other VLANs.)
user@host# set interfaces vlan unit 100 family inet address 192.168.10.1/24

  When you do that, I'm finding (if I read right) that you config the physical interface:

set interfaces ge-0/0/0 unit 0 description ge-0/0/1
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode trunk/access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members vlan-name [names]
set interfaces ge-0/0/0 unit 0 family ethernet-switching native-vlan-id 3

The other example I've found is just configure sub-interfaces on the physical interface:

set interfaces ge-0/0/0 vlan-tagging
set interfaces ge-0/0/0 native-vlan-id 100
set interfaces ge-0/0/0 unit 100 vlan-id 100
set interfaces ge-0/0/0 family inet address 192.168.1.1/24

set interfaces ge-0/0/0 unit 200 vlan-id 200
set interfaces ge-0/0/0 family inet address 192.168.2.1/24

set interfaces ge-0/0/0 unit 300 vlan-id 300
set interfaces ge-0/0/0 family inet address 192.168.3.1/24

Not sure of the question so this may be the wrong answer.

Generally if you have only one connection to the SRX for the VLAN then simply putting the address on the subinterface is best.

But if you have multiple interfaces on the SRX that need to participate in the VLAN creating the VLAN interface and group is best.

I've tried to put together a quick image of what I'm trying to connect. Hope it makes sense.

So SRX config would be something like:

   set interfaces ge-0/0/0 description "Trunk to Internet: SRX-210 (ge-0/0/0) to MOTOROLA SBG6580"
   set interfaces ge-0/0/0 gigether-options auto-negotiation
   set interfaces ge-0/0/0 unit 0 family inet address 172.20.15.254/24

   set interfaces ge-0/0/1 description "SRX-210 (ge-0/0/1) to TP-LINK port 1 : Gateway for HOME_LAN"
   set interfaces ge-0/0/1 gigether-options auto-negotiation
   set interfaces ge-0/0/1 unit 0 family inet address 10.20.15.254/24
   set interfaces ge-0/0/1 unit 0 family inet sampling input
   set interfaces ge-0/0/1 unit 0 family inet sampling output

   set interfaces fe-0/0/6 description "SRX-210 (fe-0/0/6) to ESXi eth2: Gateway for LAB_WORK"
   set interfaces fe-0/0/6 unit 0 family inet address 10.1.69.254/24

   set interfaces fe-0/0/7 description "SRX-210 (fe-0/0/7) to ESXi eth3: Gateway for LAB_VULN"
   set interfaces fe-0/0/7 unit 0 family inet address 10.16.36.254/24

Attachment(s)

R610_Network.pdf   85 KB 1 version

Thanks for the diagram makes it easier to understand.  Your configuration looks good, putting the gateway for each of those three subnets onto the SRX and since there is only one port in each VLAN the addressing goes right on the interface.

For the security policies you mention, you will create zone names for each of the subnets and assign the interfaces to those zones.

then you will write polcies from zone to zone for the traffic you wish to permit.  No policy means not traffic, the default is to deny.  And the policy is needed in the direction that initiates the ip traffic.

Sorry for the delay - have been in class. Anyway, thanks for the reply! So here's what I've come up with. Just wanted to get another pair of eyes on it:

delete interfaces fe-0/0/6
   set interfaces fe-0/0/6 description "SRX-210 (fe-0/0/6) to ESXi eth2: Gateway for LAB_WORK"
   set interfaces fe-0/0/6 fastether-options auto-negotiation
   set interfaces fe-0/0/6 vlan-tagging
   set interfaces fe-0/0/6 unit 169 vlan-id 169
   set interfaces fe-0/0/6 unit 169 family inet address 10.1.69.254/24
   set interfaces fe-0/0/6 unit 169 family inet sampling input
   set interfaces fe-0/0/6 unit 169 family inet sampling output
   set interfaces fe-0/0/6 unit 169 family inet filter input-list FLTR_IN_LAB_WORK
   set interfaces fe-0/0/6 unit 169 family inet filter input-list FLTR_IN_DFLT_DENY

delete interfaces fe-0/0/7
   set interfaces fe-0/0/7 description "SRX-210 (fe-0/0/7) to ESXi eth3: Gateway for LAB_VULN"
   set interfaces fe-0/0/7 fastether-options auto-negotiation
   set interfaces fe-0/0/7 vlan-tagging
   set interfaces fe-0/0/7 unit 1636 vlan-id 1636
   set interfaces fe-0/0/7 unit 1636 family inet address 10.16.36.254/24
   set interfaces fe-0/0/7 unit 1636 family inet sampling input
   set interfaces fe-0/0/7 unit 1636 family inet sampling output
   set interfaces fe-0/0/7 unit 1636 family inet filter input-list FLTR_IN_LAB_VULN
   set interfaces fe-0/0/7 unit 1636 family inet filter input-list FLTR_IN_DFLT_DENY


delete security address-book global address ADDR_LAB_VULN
 set security address-book global address ADDR_LAB_VULN description "LAB Vulnerable VMs domain Addresses"
 set security address-book global address ADDR_LAB_VULN 10.16.36.0/24

delete security address-book global address ADDR_LAB_WORK
 set security address-book global address ADDR_LAB_WORK description "LAB Working VMs domain Addresses"
 set security address-book global address ADDR_LAB_WORK 10.1.69.0/24


delete policy-options prefix-list LIST_LAB_WORK
delete policy-options prefix-list LIST_LAB_VULN
 set policy-options prefix-list LIST_LAB_WORK apply-path "security address-book global address ADDR_LAB_WORK <*>"
 set policy-options prefix-list LIST_LAB_VULN apply-path "security address-book global address ADDR_LAB_VULN <*>"

NOTE: THERE ARE OTHER ZONE-TO-ZONES FOR REJECT.
delete security policies from-zone LAB_WORK to-zone LAB_WORK
 set security policies from-zone LAB_WORK to-zone LAB_WORK policy LAB_WORK_LAB_WORK match application any
 set security policies from-zone LAB_WORK to-zone LAB_WORK policy LAB_WORK_LAB_WORK match destination-address ADDR_LAB_WORK
 set security policies from-zone LAB_WORK to-zone LAB_WORK policy LAB_WORK_LAB_WORK match source-address ADDR_LAB_WORK
 set security policies from-zone LAB_WORK to-zone LAB_WORK policy LAB_WORK_LAB_WORK then permit
 set security policies from-zone LAB_WORK to-zone LAB_WORK policy LAB_WORK_LAB_WORK then log session-init
 set security policies from-zone LAB_WORK to-zone LAB_WORK policy LAB_WORK_LAB_WORK then log session-close

delete security policies from-zone LAB_WORK to-zone LAB_VULN
 set security policies from-zone LAB_WORK to-zone LAB_VULN policy LAB_WORK_LAB_VULN match application any
 set security policies from-zone LAB_WORK to-zone LAB_VULN policy LAB_WORK_LAB_VULN match destination-address ADDR_LAB_VULN
 set security policies from-zone LAB_WORK to-zone LAB_VULN policy LAB_WORK_LAB_VULN match source-address ADDR_LAB_WORK
 set security policies from-zone LAB_WORK to-zone LAB_VULN policy LAB_WORK_LAB_VULN then permit
 set security policies from-zone LAB_WORK to-zone LAB_VULN policy LAB_WORK_LAB_VULN then log session-init
 set security policies from-zone LAB_WORK to-zone LAB_VULN policy LAB_WORK_LAB_VULN then log session-close

delete security policies from-zone LAB_VULN to-zone LAB_WORK
 set security policies from-zone LAB_VULN to-zone LAB_WORK policy LAB_VULN_LAB_WORK match application any
 set security policies from-zone LAB_VULN to-zone LAB_WORK policy LAB_VULN_LAB_WORK match destination-address ADDR_LAB_VULN
 set security policies from-zone LAB_VULN to-zone LAB_WORK policy LAB_VULN_LAB_WORK match source-address ADDR_LAB_WORK
 set security policies from-zone LAB_VULN to-zone LAB_WORK policy LAB_VULN_LAB_WORK then permit
 set security policies from-zone LAB_VULN to-zone LAB_WORK policy LAB_VULN_LAB_WORK then log session-init
 set security policies from-zone LAB_VULN to-zone LAB_WORK policy LAB_VULN_LAB_WORK then log session-close

delete security policies from-zone LAB_VULN to-zone LAB_VULN
 set security policies from-zone LAB_VULN to-zone LAB_VULN policy LAB_VULN_LAB_VULN match application any
 set security policies from-zone LAB_VULN to-zone LAB_VULN policy LAB_VULN_LAB_VULN match destination-address ADDR_LAB_VULN
 set security policies from-zone LAB_VULN to-zone LAB_VULN policy LAB_VULN_LAB_VULN match source-address ADDR_LAB_VULN
 set security policies from-zone LAB_VULN to-zone LAB_VULN policy LAB_VULN_LAB_VULN then reject


delete security zones security-zone LAB_WORK
 set security zones security-zone LAB_WORK description "SRX-210 (fe-0/0/6) to R610 ETH2"
 set security zones security-zone LAB_WORK interfaces fe-0/0/6.169 host-inbound-traffic system-services ping
 set security zones security-zone LAB_WORK interfaces fe-0/0/6.169 host-inbound-traffic system-services https
 set security zones security-zone LAB_WORK interfaces fe-0/0/6.169 host-inbound-traffic system-services ssh

delete security zones security-zone LAB_VULN
 set security zones security-zone LAB_VULN description "SRX-210 (fe-0/0/7) to R610 ETH3"
 set security zones security-zone LAB_VULN interfaces fe-0/0/7.1636 host-inbound-traffic system-services ping

delete firewall family inet filter FLTR_IN_LAB_WORK
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_PING from source-prefix-list LIST_LAB_WORK
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_PING from destination-address LIST_LAB_WORK
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_PING from destination-address LIST_LAB_VULN
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_PING from protocol icmp
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_PING then count CNT_ALLOW_PING
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_PING then log
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_PING then syslog
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_PING then accept

 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_SSH from source-prefix-list LIST_LAB_WORK
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_SSH from destination-prefix-list LIST_LAB_WORK
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_SSH from destination-prefix-list LIST_LAB_VULN
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_SSH from port ssh
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_SSH then count CNT_ALLOW_SSH
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_SSH then log
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_SSH then syslog
 set firewall family inet filter FLTR_IN_LAB_WORK term ALLOW_SSH then accept


delete firewall family inet filter FLTR_IN_LAB_VULN
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_PING from source-prefix-list LIST_LAB_VULN
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_PING from destination-address LIST_LAB_VULN
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_PING from destination-address LIST_LAB_WORK
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_PING from protocol icmp
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_PING then count CNT_ALLOW_PING
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_PING then log
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_PING then syslog
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_PING then accept

 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_SSH from source-prefix-list LIST_LAB_VULN
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_SSH from destination-prefix-list LIST_LAB_WORK
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_SSH from port ssh
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_SSH from tcp-established
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_SSH then count CNT_ALLOW_SSH
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_SSH then log
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_SSH then syslog
 set firewall family inet filter FLTR_IN_LAB_VULN term ALLOW_SSH then accept

Any glaring errors? Again, I appreciate all the input from the forum. You guys rock!

Based on your diagram I would have assumed that ports fe-0/0/6 adn fe-/0/0/7 were untagged single connections so this command would not be on the ports.

   set interfaces fe-0/0/6 vlan-tagging
   set interfaces fe-0/0/6 unit 169 vlan-id 169

And on the switch side these would be access ports in family ethernet switching.

The security policies look like they are correct for transit traffic.

I don't think you are using the firewall filters correcly here.  These will affect all packets crossing that physical interface and are stateless packet filters.  I think you are trying to protect the SRX self traffic.  This you restrict general protocols as you did in the security zone.  If you want to further restrict write some secuiryt policies with a to zone of Junos-host. 

Really appreciate the time to look at the config.

re: interfaces/vlan

I was thinking it better for separation to have the interfaces vlan tagged. They aren't attached to a switch but directly to the back of the Dell/esxi. And those interfaces on the esxi are vlan tagged so I guess that would take the place of the access port on the switch right? So if I want to ensure there is no communication possible and ensure they are completely isolated as far as broadcast/multicast/etc, wouldn't vlan be the best way to go? I agree, having the single interface and vlan may be redundant but .......?

re: filters

They aren't complete. I wanted to just get something there to track that packets were in fact hitting the interface and filter. Later, I'll be putting more restrictive filters in place. I've always thought it best to drop a packet as close to the source as possible so that's why I was planning on putting more restrictions on the filters and minimal restrictions on the zone policies.

When there is one and only one vlan on an interface there is no need to add tagging to the interface.  Access ports assigned to a single vlan will not have any leakage.

I've never heard of using both filters and policies in the manner you are describing and don't understand the benefit.  Policies are stateful and the best way to control communications on a firewall this is where you typically enforce traffic parameters.

---

@spuluka wrote:

When there is one and only one vlan on an interface there is no need to add tagging to the interface.  Access ports assigned to a single vlan will not have any leakage.

 

I've never heard of using both filters and policies in the manner you are describing and don't understand the benefit.  Policies are stateful and the best way to control communications on a firewall this is where you typically enforce traffic parameters.

---

Understand the single vlan access ports but I don't have any. I'm setting the interface on the SRX as the L3 gateway for that vlan/network. Access ports would need to be defined as ethernet-switching instead of inet correct?

Filters vs policy: As I was teaching myself Juniper with my limited networking skills, I was constantly reminded of the flow diagram. This was instrumental in learning to troubleshoot packet flow as well as design a secure configuration. Given that the first things that happen are the policer and filter, it always seemed appropriate to limit what makes it into the processing engine as early as possible. If the device can simply throw the packet away before it wastes any CPU time on determing where it's supposed to go, isn't that the most efficient way?

I agree completely on doing any stateful evaluation at the zone policies and I will probably do some there once I know things are working and passing traffic. So I is that wrong? Is it not good practice to drop the packet as close to the source as possible?

Also, I do believe you and agree on the state-ful/less nature of the two but I'm wondering why there is a 'from tcp-established' option in the firewall filters?

Anyway, I really do appreciate your input and patience! 

From the diagram I was only seeing one vlan assigned to ports fe-0/0/6 and fe-0/0/7 so these would be untagged.  But if they actually have more than one vlan terminating on the port vlan tagging would be needed.

On the filtering in addition to policies, remember that the full policy lookup chart you are examining happens only on the FIRST packet for the entire flow.  After that the sesson is matched and there is no further processing.  While the complex multi-stage packet filter you are creating here will process every single packet on all the interfaces as they enter.  I don't see any processing benefit.

And the filtering process will be more complex and convoluted.  Plus since it is not stateful you need to create opposite filters then on the inbound and outbound zone interfaces.  this type of system is asking for mistakes to occur.

Using this for logging is likewise complex, all you get is a simple count per term added.  And you need to check both sides during the issue.  Simpler is to add logging to the policy which will generate all the flow information in a single record.  And these can be shipped to syslog for longer term storage as well.

So for the interfaces, I can still keep them L3 and just use unit 0? If a broadcast to 255 comes across that interface, won't the SRX process that and send it to the other interfaces of am I confusing things?

Absolutely understand that the full policy lookup only occurs on the first packet. One of the things think is great about the processing engine/process and the way Juniper has coded their engines.

The one benefit that I get on the filters is that my syslog server will register a firewall deny message which will help me to troubleshoot knowing that A: the packet did hit the interface I was expecting, and B:allow me to verify if there are odd port/protocols involved. Obviously for simple things like SSH and HTTP it's not needed but isn't there also the ability to be more granular at the filter than on the policy? Again, all of my training is self taught using Juniper's YouTube channel and lots of reading through the KBs here.

The logging of policies only produce session-init and session-close, correct? So how would I be able to know that my policy blocked something? If it's blocked, then session-init is never generated. That's kinda why I use the filters. That ensures that I know the packet made it from point A to at least the SRX. Then I can enable trace-options using the IP/port/protocol/etc. to follow the packet through.

I'm guessing too that maybe there is a lot of troubleshooting/tracing aides in J-Web? I don't use that and only use the CLI as that's what I'm confortable with.

Again, I really appreciate your input!!!

So for the interfaces, I can still keep them L3 and just use unit 0?
If a broadcast to 255 comes across that interface, won't the SRX process
that and send it to the other interfaces of am I confusing things?

Yes, I think you are confusing things.  Broadcast is only within a layer 2 domain so it would stay in the subnet.

Tags were invented so that multiple vlans can share the same physical port.  If the port has only one vlan no tags are needed.

logging

The implict deny rules that you don't need to configure will not log.  But when you create a deny rule you have the option to add log at session init and these then will log locally.  You can also choose to send policy logs to syslog servers, including deny policy logs.

Trace options are used when nothing in the logs easily explains what is occuring and you can capture more detialed data about the flow processing for the problem traffic.

The implicit deny rules that you don't need to configure will not log.
But when you create a deny rule you have the option to add log at session init and these then will log locally.
You can also choose to send policy logs to syslog servers, including deny policy logs.

I'll have to try this and see what the log looks like but I'm thinking that at my syslog server (using vJSA) I'll just see a "session-init" message which doesn't tell me that the packet was denied. In fact, I would probably initially see that as a session was created for the packet. So logically, to me at least, that would not make sense unless it would show a session-deny message.

Do you have a link to a good KB on how to manage syslog messages from zone policies?

On a deny policy you get messages on the denied traffic using log session init.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB16509

To enable logging for a security policy that has a deny action, you must specify that traffic logs are generated when a session starts. 

To enable logging for a security policy:  (Either or both steps can be configured.)

1. For the default-permit security policy, specify that traffic logs are generated when a session closes.

   user@host# set security policies from-zone trust to-zone untrust policy default-permit then log session-close

2. (Optional) Specify that traffic logs are generated when a session starts. 

syslog setup for policy logging

https://kb.juniper.net/InfoCenter/index?page=content&id=KB16509