Thứ Ba, 21 tháng 10, 2014

Two Ways of Setting Up Trunks on Juniper Switches

In a previous blog, I’ve shown you how to create VLANs on a Juniper switch, particularly running JunOS. Furthermore, I’ve shown you how to edit the vlan membership using two methods. In this blog, I will now show you the two methods for setting up a trunk.
But let’s quickly review what a trunk is, since this is actually important towards understanding the configuration logic.
Depending on how deep you want to dive into it, there is actually quite a bit of theory behind trunk links, from the switch logic itself, all the way to protocols, standard, encapsulation, etc. Though for the sole purpose of this blog, let’s just agree on the following definition:
A trunk port is  a logical link which can transport frames for more than one VLAN.
Outgoing frames going out a trunk port will be tagged with the VLAN tag, unless the frame belongs to the native-vlan. This is the default behaviour which, could be changed in configuration.
Incoming frames are inspected and the switch forwards them based on the vlan-tag found within the frame (when one exists).
How does the switch know that a frame has a tag? When a frame is received, the switch will read the Ethernet frame, particularly, the EtherType field. In regards to trunking, the following values are possible: 0×9100 – QinQ encapsulation; 0×8100 – VLAN Tagging.
Without going into more advanced scenarios, we need trunks to accommodate, primarily, two scenarios:trunks-01
  1. Router on a stick
  2. Interconnection between switches
Let’s now see how do we configure a trunk on a Juniper switch running JunOS. I will be using the following topology:
vlans-03
METHOD I
The logic here is to configure a logical interface belonging to more than one VLAN – kind of makes sense, if you understood the actual purpose of a trunk port! Next, I will configure interface/port ge-0/0/23 so that it belongs to both vlans VLAN-10 and VLAN-20 respectively…
Note: Keep in mind that I will skip over the configuration of the actual VLANs for this has already been explained here. I have also removed some lines from the output for added clarity.
{master:0}[edit]
root# show vlans
VLAN-10 {
   vlan-id 10;
   interface {
      ge-0/0/23.0;
   }
}
VLAN-20 {
   vlan-id 20;
   interface {
      ge-0/0/23.0;
   }
}
default {
vlan-id 1;
interface {
ge-0/0/23.0;
}
}

… and the set commands:
{master:0}[edit]
root# show vlans | display set
set vlans VLAN-10 interface ge-0/0/23.0
set vlans VLAN-20 interface ge-0/0/23.0
But, when I try to commit the configuration, I get an error!!!
root# commit check
error: Access interface <ge-0/0/23.0> has more than one vlan member: <VLAN-20> and <VLAN-10>
error: configuration check-out failed
The reason why we get this error is that, although we’ve configured the port for Layer2 (using the ethernet-switching property), by default, the port is an access port. In order to setup this port as a trunk port, we need to run the following set command:
{master:0}[edit]
root# set interfaces ge-0/0/23 unit 0 family ethernet-switching port-mode trunk
{master:0}[edit]
root# show interfaces ge-0/0/23
unit 0 {
   family ethernet-switching {
      port-mode trunk;
      native-vlan-id 1;
   }
}
Notice the native-vlan-id 1 command - this is telling the switch that the native-vlan on this trunk is the VLAN with the vlan-id 1.
We can now successfully commit the configuration!
{master:0}[edit]
root# commit
fpc0:
configuration check succeeds
fpc1:
commit complete
fpc0:
commit complete
METHOD II
The 2nd method goes by the same logic applied on the 2nd method of editing VLAN membership – when setting up trunks, instead of “attaching” a VLAN to an interface, we “attach” multiple VLANs to the same interface.
To demonstrate, I’ve removed the previous configuration used with METHOD I.
Here is the configuration snippet:
ge-0/0/23 {
   unit 0 {
      family ethernet-switching {
         port-mode trunk;
         vlan { 
            members [ VLAN-10 VLAN-20 ];
         }
         native-vlan-id 1;
      }
   }
}
… and the set commands:
{master:0}[edit]
root# show interfaces | display set
[...]
set interfaces ge-0/0/23 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/23 unit 0 family ethernet-switching vlan members VLAN-10
set interfaces ge-0/0/23 unit 0 family ethernet-switching vlan members VLAN-20
set interfaces ge-0/0/23 unit 0 family ethernet-switching native-vlan-id 1
Let’s take a look at two show commands:
{master:0}[edit]
root# run show vlans extensive
VLAN: VLAN-10, Created at: Fri Sep 13 06:41:32 2013
802.1Q Tag: 10, Internal index: 2, Admin State: Enabled, Origin: Static
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 1 (Active = 1), Untagged 2 (Active = 0)
             ge-0/0/23.0*, tagged, trunk
             ge-0/0/10.0, untagged, access
             ge-0/0/11.0, untagged, access
VLAN: VLAN-20, Created at: Fri Sep 13 08:32:16 2013
802.1Q Tag: 20, Internal index: 5, Admin State: Enabled, Origin: Static
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 1 (Active = 1), Untagged 2 (Active = 0)
             ge-0/0/23.0*, tagged, trunk
             ge-0/0/20.0, untagged, access
             ge-0/0/21.0, untagged, access
VLAN: default, Created at: Fri Sep 13 06:41:32 2013
802.1Q Tag: 1, Internal index: 3, Admin State: Enabled, Origin: Static
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 1 (Active = 1), Untagged 1 (Active = 1)
             ge-0/0/23.0*, tagged, trunk
            ge-0/0/23.0*, untagged, trunk
__________________________________________________________
{master:0}[edit]
root# run show ethernet-switching interfaces
Interface State VLAN members Tag Tagging Blocking
bme0.32770 down mgmt untagged unblocked
ge-0/0/10.0 down VLAN-10 10 untagged blocked by STP
ge-0/0/11.0 down VLAN-10 10 untagged blocked by STP
ge-0/0/20.0 down VLAN-20 20 untagged blocked by STP
ge-0/0/21.0 down VLAN-20 20 untagged blocked by STP
ge-0/0/23.0 up default 1 untagged unblocked
                                 VLAN-10 10 tagged unblocked
                                 VLAN-20 20 tagged unblocked
                                 default 1 tagged unblocked
me0.0 down mgmt untagged unblocked

Thank you,
source : http://blogbt.net/index.php/2014/09/setting-up-trunks-juniper-switches/
Người đăng: vào lúc Không có nhận xét nào:

Two Ways of Setting Up VLANs on Juniper Switches

With Cisco IOS, when it comes to setting up a VLAN and VLAN Membership, the process is in fact very straight forward. JunOS give us two ways of setting up a VLAN’s membership – regardless the method you use, the result will be exactly the same.
Q: Isn’t this already explained on Juniper’s website?
A: Yes, it is!
Q: So why would you carry on reading?
A: I reckon that, on Juniper’s website some things are not clear. Secondly, I will be showing you a few  gotchas which Juniper doesn’t mention either – this will mostly relate to the implementation logic.
As usually, let’s see a diagram:
vlans-01
So we will setup two VLANs – there is one way only for creating a VLAN; we will use the following set commands:
root# run show configuration vlans
VLAN-10;
vlan-20 {
    vlan-id 20;
}
{master:0}[edit]
root# run show configuration vlans | display set
set vlans VLAN-10
set vlans vlan-20 vlan-id 20
Few things already to observe here:
  1. When creating a VLAN, we give it a name, a vlan-id, or both! Should a vlan-id not be specified, that vlan will handle untagged frames. On Juniper’s website it is mentioned that the vlan-id is automatically generated – I could not verify this, as shown below. You can see that tagging is only enabled for VLAN-20.
  2. Another thing we notice is that by default, there is already a VLAN setup on the switch – this is called the default vlan and it carries untagged frames. Unlike Cisco switches, it *does not* have the vlan-id 1. Here is something very cool: even though both vlans (default & vlan-10) carry untagged frames, the broadcast domain is still separate!
{master:0}[edit]
root# run show vlans detail
VLAN: VLAN-10, 802.1Q Tag: Untagged, Admin State: Enabled
VLAN: default, 802.1Q Tag: Untagged, Admin State: Enabled
VLAN: vlan-20, 802.1Q Tag: 20, Admin State: Enabled
{master:0}[edit]
root# run show vlans extensive
VLAN: VLAN-10, Created at: Fri Sep 13 07:32:47 2013
Internal index: 4, Admin State: Enabled, Origin: Static
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 0 (Active = 0), Untagged 0 (Active = 0)
VLAN: default, Created at: Fri Sep 13 06:41:28 2013
Internal index: 3, Admin State: Enabled, Origin: Static
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 0 (Active = 0), Untagged 0 (Active = 0)
VLAN: vlan-20, Created at: Fri Sep 13 07:32:47 2013
802.1Q Tag: 20, Internal index: 5, Admin State: Enabled, Origin: Static
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 0 (Active = 0), Untagged 0 (Active = 0)
Let’s now move onto the two methods of creating the VLAN membership – i.e., which ports belong to which vlan.
METHOD I
The configuration logic allows to specify under the vlans configuration hierarchy, which interfaces are part of that particular vlan. In our case, I want to add interfaces go-0/0/10 & go-0/0/11 to vlan 10. So all I need to do is “drill down” into the vlan-10 configuration hierarchy and add the relevant interfaces. I will call this Juniper’s way!
Now watch this:
{master:0}[edit]
root# edit vlans
{master:0}[edit vlans]
root# edit VLAN-10
root# set interface ?
Possible completions:
<interface_name> Interface name that uses this VLAN
vcp-255/0/0.32768
vcp-255/0/1.32768
bme0.32768
bme0.32770
lo0.16384
me0.0
…
So where the heck are my Gigabit interfaces!?
Here is the thing: you can only work with Layer2 interfaces. The reason why our interfaces are not listed is very simple! As far as JunOS is concerned, the gigabit interfaces are not currently setup for switching.
NOTE that by default, all switch ports are configured for switching. I have however removed the default configuration in order to make a point! It is useful to know this because you may come across scenarios where a specific port was configured for a different purpose …
Since we’ll use a total of four interfaces as Layer2 switching ports, let’s just configure them as such:
{master:0}[edit]
root# run show configuration interfaces | display set
set interfaces ge-0/0/10 unit 0 family ethernet-switching
set interfaces ge-0/0/11 unit 0 family ethernet-switching
set interfaces ge-0/0/20 unit 0 family ethernet-switching
set interfaces ge-0/0/21 unit 0 family ethernet-switching
root# run show configuration interfaces
ge-0/0/10 {
   unit 0 {
      family ethernet-switching;
   }
}
ge-0/0/11 {
   unit 0 {
      family ethernet-switching;
    }
}
ge-0/0/20 {
    unit 0 {
      family ethernet-switching;
    }
}
ge-0/0/21 {
    unit 0 {
       family ethernet-switching;
    }
}
Following the actions above, let’s try again make ge-0/0/10 – 11 interfaces, part of vlan 10:
{master:0}[edit]
root# edit vlans
{master:0}[edit vlans]
root# edit VLAN-10
{master:0}[edit vlans VLAN-10]
root# set interface ?
Possible completions:
<interface_name> Interface name that uses this VLAN
vcp-255/0/0.32768
vcp-255/0/1.32768
ge-0/0/10.0
ge-0/0/11.0
ge-0/0/20.0
ge-0/0/21.0
bme0.32768
bme0.32770
lo0.16384
me0.0
{master:0}[edit vlans VLAN-10]
root# set interface ge-0/0/10
{master:0}[edit vlans VLAN-10]
root# set interface ge-0/0/11
{master:0}[edit vlans VLAN-10]
root# show
interface {
    ge-0/0/10.0;
    ge-0/0/11.0;
}
… and the relevant set commands:
{master:0}[edit vlans VLAN-10]
root# run show configuration vlans | display set
set vlans VLAN-10 interface ge-0/0/10.0
set vlans VLAN-10 interface ge-0/0/11.0
set vlans vlan-20 vlan-id 20
METHOD II
METHOD II 
The second method attaches a vlan to a specific interface; hence the configuration is done within the interfaces hierarchy. This is more like Cisco way of doing it …  Let’s use this method to configure membership for vlan-20:
{master:0}[edit]
root# show interfaces | display set
[...] set interfaces ge-0/0/20 unit 0 family ethernet-switching vlan members vlan-20
set interfaces ge-0/0/21 unit 0 family ethernet-switching vlan members vlan-20
root# show interfaces
[...] ge-0/0/20 {
     unit 0 {
        family ethernet-switching {
            vlan {
                members vlan-20;
             }
         }
    }
}
ge-0/0/21 {
      unit 0 {
         family ethernet-switching {
             vlan {
                 members vlan-20;
             }
         }
     }
}
This is it! In a way, using the 2nd method, the vlan becomes a kind-of property of the ether-switching feature.
Let’s run two show commands:
{master:0}[edit]
root# run show vlans extensive
VLAN: VLAN-10, Created at: Fri Sep 13 07:32:47 2013
Internal index: 4, Admin State: Enabled, Origin: Static
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 0 (Active = 0), Untagged 2 (Active = 0)
ge-0/0/10.0, untagged, access
ge-0/0/11.0, untagged, access
VLAN: default, Created at: Fri Sep 13 06:41:28 2013
Internal index: 3, Admin State: Enabled, Origin: Static
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 0 (Active = 0), Untagged 0 (Active = 0)
VLAN: vlan-20, Created at: Fri Sep 13 07:32:47 2013
802.1Q Tag: 20, Internal index: 5, Admin State: Enabled, Origin: Static
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 0 (Active = 0), Untagged 2 (Active = 0)
ge-0/0/20.0, untagged, access
ge-0/0/21.0, untagged, access
Also notice that these ports are not actually active – this is because there are no hosts attached to them.


Thank you,
source: http://blogbt.net/index.php/2014/09/two-ways-setting-vlans-juniper-switches/
Người đăng: vào lúc Không có nhận xét nào:

VLAN Trunking – Cisco (IOS) vs Juniper (JunOS)

While introducing my Juniper switches into my home/lab network, I came across few interoperability issues with my Cisco switches. I guess I ought to give you a very brief background so you understand how this all started. I will do so, while I’ll also introduce the topology I’ll work on for this blog.
vlan-ios-junos-02
The Cisco 2960 switch is sitting behind my TV and this is currently handling my LAN/Home network.
The Juniper EX2200 is sitting in my conservatory; this will be set as my breakout Layer3 switch to/from my Lab network (I initially had a Cisco box which I got rid off on eBay – you can see my previous setup here). To achieve connectivity between the two “sites”, I’m using two TP-Link power line adapters - the result is a Layer2 pseudo wire over my home power network.
As I’m trying to trunk between these two switches, I ran into some issues … But let’s get at the command line …
Below you can see my configuration for both devices – but can you see the problem?
screenshot278 screenshot281
Well … if you can, then you are awesome! If you can’t, then I can assure you, I was in the same boat – we are still awesome though!
screenshot280
The problem is that, in regards to the native VLAN, Cisco and Juniper do not work the same way. With JunOS, in many cases, you will have to be more explicit; the defaults won’t get the job done – this is good for security; but it does add head-aches.
Notice how I’m allowing all my VLANs to the trunk - in Juniper’s world, this includes VLAN-1. Since we haven’t *explicitly* specified our native vlan, the Juniper switch will tag the frames going out this port; as far as the Juniper’s switch is concerned, vlan-1 is just another vlan! Incoming frames, will also be rejected for the same reason (notice the “Untagged 0 (Active = 0)“).
screenshot282
ok … so let’s tell the switch that VLAN-1 is the native vlan …
screenshot283 screenshot280
… and it is still *not* working! Let’s check the show vlans output again:
screenshot285
The 1st to the last line, shows the settings for outbound frames; similarly, the last line shows the settings for the inbound frames; when there is only one line present, it means that the settings are the same for incoming and outgoing frames.
What this output is telling us is that, should the switch receive an *untagged* frame, it will be assigned to VLAN-1. In case the frame is tagged with Vlan-id of 1, the switch will behave the same as for any other tagged frame – in this case, it will also get assigned to vlan VLAN-1. However, outgoing frames, will still be tagged – the default behaviour being the same as with Cisco, when the vlan dot1q tag native command is applied!
So we are still sending tagged frames which Cisco won’t like! Not good!
Now we have two options:
  1. We apply the vlan dot1q tag native command, forcing the switch to tag and accept tagged frames, even for the native vlan
  2. We get the Juniper switch not to tag frames on the native vlan
The Cisco 2960 *does not* support that command though!
To enable the 2nd option, all we need to do is remove vlan 1 from the trunk – very easy !!
screenshot286
… and now our pings work!
screenshot287
At last, let’s check what changed on the show vlans output:
screenshot288
We can now see that the switch will send vlan-1 frames, untagged; furthermore, incoming untagged frames will be assigned to vlan-1. The switch, will also accept and be able to send tagged frames – since it’s a trunk port.

Thank you,
source: http://blogbt.net/index.php/2014/09/vlan-trunking-cisco-ios-vs-juniper-junos/
Người đăng: vào lúc Không có nhận xét nào:

Thứ Năm, 16 tháng 10, 2014

SRX for beginners

I was thinking if I should write a short article for beginners to quickly configure an SRX firewall.
I don’t know how many people will find it useful but I hope it will be for those who use SRX for
the first time in their life.  Let’s get started.
Our topology in this tutorial is below;


srx_beginner
We will configure the followings from scratch:
  1. Loading default config and setting the root password
  2. Configuring interfaces and default route
  3. Configuring security zones
  4. Configuring address book entries
  5. Creating security policies
  6. Creating source nat for internal clients


Loading default config and setting the root password

I assume you are connected to the SRX device via console
[stextbox id="grey" caption=CLI]
[edit]
root# load factory-default
warning: activating factory configuration
[edit]
root# set system root-authentication plain-text-password
New password:
Retype new password:
[edit]
root# set system host-name srx220
[edit]
root# commit
commit complete
[edit]
root@srx220#
[/stextbox]
Once we commit the changes, we should see the new hostname srx220 in the prompt.

Configuring interfaces and default route


Interfaces
[stextbox id="grey" caption="CLI"]
#delete interfaces ge-0/0/0
#delete interfaces ge-0/0/1
#set interfaces ge-0/0/0 unit 0 family inet address 192.168.100.38/24
#set interfaces ge-0/0/1 unit 0 family inet address 192.168.239.1/24
[/stextbox]
Default route
[stextbox id="grey" caption="CLI"]
#set routing-options static route 0.0.0.0/0 next-hop 192.168.100.1
[/stextbox]

Configuring security zones

SRX is a zone based firewall and you must assign each interface to a zone to be able to pass traffic through.
There must be two default zones trust and untrust coming with the factory-default config but we will delete them
and configure our own zones.  Following will be our zone configuration;
  • Our zone facing pc clients is named internal
  • zone facing internet is named internet
  • Internal clients will be able to reach SRX i.e ping and ssh service will be enabled towards SRX
[stextbox id="grey" caption="CLI" collapsing="true"]
#set security zones security-zone internal interfaces ge-0/0/1.0 host-inbound-traffic system-services ping
#set security zones security-zone internal interfaces ge-0/0/1.0 host-inbound-traffic system-services ssh
#set security zones security-zone internet interfaces ge-0/0/0.0
[/stextbox]
Now we have assigned interfaces to each zone.

Configuring address book entries

If you want to configure a security policy you must create an address book entry for the network ranges you would like to use.
We will create one address book entry for our internal network block 192.168.239.0/24 as follows;
[stextbox id="grey" caption="Address Book "]
#set security zones security-zone internal address-book address network_239 192.168.239.0/24
[/stextbox]
Our address book entry is also ready for security policy. Now it is time to enforce the security policy to allow internal users to access outside networks.

Creating security policies

We first start with deleting already existing policies
[stextbox id="grey" caption="Security Policies"]
#delete security policies
#set security policies from-zone internal to-zone internet policy allow-internal-clients match source-address network_239
#set security policies from-zone internal to-zone internet policy allow-internal-clients match destination-address any
#set security policies from-zone internal to-zone internet policy allow-internal-clients match application any
#set security policies from-zone internal to-zone internet policy allow-internal-clients then permit
[/stextbox]
A policy is must be placed within a context which means the direction of the policy e.g from internal zone to internet zone
with this configuration we enabled traffic from internal clients to internet zone.

Creating source nat for internal clients

You may also need to source NAT internal clients with your outside interface IP address. Here is how we configure source nat in SRX:
First start deleting previous left over nat rules.
[stextbox id="grey" caption="CLI"]
#delete security nat
#set security nat source rule-set internal-to-internet from zone internal
#set security nat source rule-set internal-to-internet to zone internet
#set security nat source rule-set internal-to-internet rule internet-access match source-address 192.168.239.0/24
#set security nat source rule-set internal-to-internet rule internet-access match destination-address 0.0.0.0/0
#set security nat source rule-set internal-to-internet rule internet-access then source-nat interface
[/stextbox]
and last commit the changes!

As you can see source NAT is also a context based configuration. You define from which zone you are coming and to which zone you are heading.
After these configuration your internal clients whose gateway is 192.168.239.1 should be able to reach Internet if I haven’t made any mistake so far.
source : http://rtoodtoo.net/2012/12/12/juniper-srx-for-beginners/#more-938
Người đăng: vào lúc Không có nhận xét nào:

Port Scanner in Python

Python is a great tool to do some socket operations. I have written a piece of code by which I can scan a port range.
It is very basic and missing bunch of checks as aim is the simplicity here.

#!/usr/bin/python
 
import socket,sys
 
try:
  sys.argv[3]
except:
  print "Usage: port_scanner.py [hostname|IP] [port_start] [port_end]"
  sys.exit()
 
host = sys.argv[1]
start_port = int(sys.argv[2])
end_port = int(sys.argv[3])
 
#CREATE SOCKET
try:
  s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
except socket.error,err_msg:
  print 'Socket creation failed. Error code: '+ str(err_msg[0]) + ' Error mesage: ' + err_msg[1]
  sys.exit()
 
#RESOLVE HOSTNAME
try:
  remote_ip = socket.gethostbyname(host)
 
except socket.error,error_msg:
  print 'ERROR:'
  print error_msg
  sys.exit()
 
#ITERATE PORT RANGE
end_port+=1
for port in range(start_port,end_port):
  try:
    s.connect((remote_ip,port))
    print 'port ' + str(port) + ' open'
 
    s.close()
    s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
  except socket.error:
    pass
 
You can run the script in the following way by which you scan ports between 1 and 1024:
[stextbox id="grey" caption="portscanner"]
$ ./port_scanner.py remotehost.com 1 1024
port 80 open
port 443 open
[/stextbox]
However I need to give some more info in here. If you send a TCP SYN segment to a closed port, normal behavior is to send a TCP RST segment back to the source. Under normal circumstances script runs through the port range and knocks every port on the remote destination. If a TCP RST is received, socket is closed and script knocks the other port in the list but what if you don’t receive any TCP RST back? For example there is a firewall in between and you can’t even knock some ports. Then what happens?  In this case Linux kernel does 5 TCP SYN by default according to my ubuntu sysctl settings;
[stextbox id="grey" caption="sysctl"]
$ sysctl -a | grep tcp_syn_retries
net.ipv4.tcp_syn_retries = 5
[/stextbox]
This is a terrible setting which causes lots of delay in every port knock. That is why to speed up test I decrease this retry value to 1 temporarily
[stextbox id="grey" caption="sysctl"]
# sysctl net.ipv4.tcp_syn_retries=1
net.ipv4.tcp_syn_retries = 1
[/stextbox]
Actually I wanted to set my own retry scheme via python but it seems it isn’t possible to manipulate kernel’s behavior on this.  In python there is a “setsockopt” method of socket by which you can send certain options but no related option I could find in socket manual of Linux. There may be a way but I don’t know it yet.
When you run the test,  you can check the SYN requests with the following tcpdump command, you can have a better picture of what the script is doing;
[stextbox id="grey" caption="tcpdump"]
#tcpdump -nni any host remotehost.com and ‘tcp[tcpflags] & tcp-syn!=0′
[/stextbox]


source : http://rtoodtoo.net/2012/12/20/port-scanner-in-python/#more-964
Người đăng: vào lúc Không có nhận xét nào:

SRX Transparent Mode

SRX can also function as a firewall device when it is in layer 2 mode i.e
it can perform firewall functionality transparently.
As of now there are certain limitations on transparent mode. If not changed already;
  • You can either run the firewall in route mode or transparent mode but not mixed
  • NAT and IPSEC aren’t supported in this mode
Below I will try to show how you can convert an SRX firewall to transparent mode
and configure it. In our topology, we have two Linux servers each in the same VLAN
(282) and we will inspect traffic between these nodes without those Linux hosts are
being aware of SRX
transparent_mode_srx

First of all converting to transparent mode means putting the interface families
to bridge. There isn’t any switch/knob by which you can convert to transparent.
You can start by deleting all interfaces config to start from scratch and configure
these two GE interfaces with interface mode access and vlan-ids. You also see an IRB
interface. We can think of this as a virtual interface on this vlan something like
vlan.282 when we are in L3 mode.
Then configure a bridge domain. Yeah but what is a bridge domain? Assume this isn’t
an SRX device but an EX switch. By assigning ge-0/0/1 and ge-0/0/2 to vlan 282 we are creating a broadcast segment and with the following config, we give BD282 name to
our new domain and assign irb.1 interface to this bridge domain to access the box i.e from any device on this vlan you can connect to SRX through irb interface as long
as the security zone of the ingress interface has the necessary system-services allowed.
If you commit after this configuration, you must be instructed to reboot which is required.
Now configure security zones and a simple security policy for testing.
Now we should be able to connect connect from hostP(5.5.5.3) to hostN(5.5.5.2). Let do SSH
and check session table and mac table on SRX
Yes SRX has learned mac addresses and flow session is installed from 5.5.5.3 to 5.5.5.2
You can also configure interfaces on trunk mode. For more information better to
check SRX layer 2 bridging and switching document.
source : http://rtoodtoo.net/2014/07/20/srx-transparent-mode/#more-2059
Người đăng: vào lúc Không có nhận xét nào:

Trunk between Cisco,EX switch and SRX


cisco2950switchex2200com
Today I needed to test communication between a Cisco switch and EX switch to carry traffic via a trunk port from a PC to
the final destination SRX device. I thought it is worth putting my config here for future reference as I am not working with cisco/ex switches much.
Above is my exact topology and I carry traffic from a PC in Vlan 200 to the port fe-0/0/7 in SRX which is in vlan 200 as well. Here is the config from Cisco switch till to SRX.

[stextbox id="grey" caption="cisco2950 config"]
cisco2950#show run interface fa0/1
Building configuration…
Current configuration : 109 bytes
!
interface FastEthernet0/1
 switchport access vlan 200
 switchport mode access
 spanning-tree portfast
end
cisco2950#show run int fa0/24
Building configuration…
Current configuration : 57 bytes
!
interface FastEthernet0/24
switchport mode trunk
end
cisco2950#show run vlan 200
Building configuration…
Current configuration:
!
vlan 200
 name vlan200
end
 vtp mode transparent
[/stextbox]
In an nutshell, we set the port fa0/1 to access mode assign vlan 200 and set port fa0/24 to trunk . Then we create the vlan 200 and set the vtp mode to transparent
[stextbox id="grey" caption="EX2200 Config"]
[edit]
root@ex2200-1# show interfaces ge-0/0/10
unit 0 {
    family ethernet-switching {
        port-mode trunk;
        vlan {
            members vlan200;
        }
    }
}
[edit]
root@ex2200-1# show interfaces ge-0/0/11
description “SRX100 TRUNK”;
unit 0 {
    family ethernet-switching {
        port-mode trunk;
        vlan {
            members all;
        }
    }
}
[/stextbox]
In EX side, we set ge-0/0/10 and ge-0/0/11 ports to trunk. I have only set vlan200 on ge-0/0/10 port as I have no other vlan there.
[stextbox id="grey" caption="SRX Config"]
[edit]
root@srx100-1# show interfaces fe-0/0/7
unit 0 {
    family ethernet-switching {
        port-mode trunk;
        vlan {
            members all;
        }
    }
}
[edit]
root@srx100-1# show interfaces vlan.200
family inet {
    address 192.168.200.1/24;
}
[/stextbox]
SRX side is also similar to EX. I set the EX facing interface fe-0/0/7 to trunk to accept any vlan traffic and vlan.200 interface to 192.168.200.1
Once I ping from the PC having address 192.168.200.100
[stextbox id="grey" caption="ping"]
root@asus:~$ ping 192.168.200.1
PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data.
64 bytes from 192.168.200.1: icmp_req=1 ttl=64 time=0.540 ms
64 bytes from 192.168.200.1: icmp_req=2 ttl=64 time=0.532 ms
^C
— 192.168.200.1 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.532/0.536/0.540/0.004 ms
[/stextbox]
You can see how it works!
source : http://rtoodtoo.net/2013/03/13/trunk-between-cisco-ex-switch-and-srx/
Người đăng: vào lúc Không có nhận xét nào:
Đăng ký: Bài đăng (Atom)