I am reading some VPN examples from the O'Reily Juniper SRX Series book. One thing I'm not clear on, and I've been unable to find additional information in the Junos documentation, is the full behavior of the permit tunnel security policy action. In particular I'm looking at an example of a policy-based VPN configuration that includes the policy:

[edit security policies from-zone untrust to-zone trust policy Remote-Client]

match {
  source-address any;
  destination-address 10.0.0.8/8;
  application any;
} then {
  permit {
    tunnel {
      ipsec-vpn Remote-Client;
    }
  }
}

I keep looking at this policy and thinking somehow it will be interpreted as permit all traffic from all sources, using the tunnel if possible... I know that's wrong but I can't shake the idea.

Is it correct (or at least reasonable) to view the permit tunnel action as being both an action and a match condition? In other words can the above policy be described as "Allow all traffic from the Remote-Client tunnel traveling from untrust to trust through."

Thanks

Hi Ecartner,

On the SRX  there are two types of tunnel route and policy based. Below is an example of the policy based vpn tunnel.

Using the security policy below the policy-based vpn tunnel will be triggered.

In the below example policy is from Untrust to trust , hence any esp traffic hitting the external interface in Untrust zone would be decrypted using the below policy.

The source and destination used in the policy would act as proxy-id ( encryption domain) for the vpn tunnel and hence it is suggested to use only a sigle pair of source and destination in a security policy when ipsec vpn is called in it.

Remote-Client is the name iof the ipsec vpn defined under the heirarchy :

set security ipsec vpn Remote-Client

Regards

Hemant

Hello,

In Policy Based VPN tunnel the policy with the permit tunnel action serves the following purpose.

1. Get the Proxy ID's for the negotiation of IKE Phase 2. (This is taken from the policy created from trust to untrust and with an action permit tunnel)
2. The policy from the trust to untrust also matches the traffic and sends it over the VPN tunnel whenever the traffic is initiated from the trust zone.
3. Then there is a pair policy from untrust to trust which is the mirror image of the policy from trust to untrust and the action permit tunnel.  It allows the traffic to pass which is reaching the SRX on the specified tunnel if it is specfied in the source and destination addresses respectively.

Hence in a sense your understanding for the secuirty policy from untrust to trust "Allow all traffic from the Remote-Client tunnel traveling from untrust to trust through." is correct becasue the policy will mean that any source if tries to reach your subnet 10.0.0.0/8 over the VPN tunnel Remote-client from untrust zone then it should be permitted.

Hence you are correct that the permit tunnel acts an action item as well as a match condition ( atleast for the pair policy from untrust to trust) 

For more information on pair policy please refer the following document:-

http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/ipsec-policy-based-vpn-configuring.html

Thanks,
Pulkit Bhandari

Please mark my response as Solution Accepted if it Helps, Kudos are Appreciated too.

Thank you for the response. That makes perfect sense. I've been out that past several days once I get caught up on some things I'll try that config out.

Hi spuluka,,

Thanks for your reply. I understand you however Could you show me how can I do it?? I don´t find any command.

I want that this broadcast only will be possible trough only one interface, If one packet arrive to another interface (in the same bridge domain) I want that it will drop it.

Is this possible??

Thanks.

Regards.

Hi,

I have seen this one,

bridge-domains {
vlan100 {
domain-type bridge;
vlan-id 100;
interface ge-2/2/1.100;
interface ae1.100;
}
vlan200 {
domain-type bridge;
vlan-id 200;
interface ge-2/2/1.200;
interface ge-2/2/6.200;
interface ae1.200;
}
vlan201 {
domain-type bridge;
vlan-id 201;
}

However, I don´t understand where can create one bridge dominain whit vlans, Would be like this?

bridge-domains {
vlans {
    default {
        l3-interface vlan.17;
    }
    vlan10 {
        vlan-id 10;
        l3-interface vlan.10;
    }

}

Then If I send one brodcast trough vlan.17, the vlan.10 will be receive it??

Thanks.

Regards.

The first confguration example is creating the bridge domains where all the members of the domain will be in the same broadcast domain.  This is your desired configuration.

But you really cannot control this for only one interface as you ask in your previous post.  Broadcast by definition means that it floods to the entire broadcast domain.  You can't have a partial broadcast.

The second configuration example is used to add a layer 3 interface into a broadcast domain.  This you probably don't need as you are likely using interface configuration on your SRX to create the layer 3 interfaces.

I get the sense that you are trying to use the wrong tool for the job here.  Just what network communications issue are you trying to achieve?  

It is sounding more likely to me that you don't really want a bridged broadcast domain at all but are trying to use broadcast packets to solve some other issue.  Or at least the descriptions are coming off as looking to acheive non-standard network behaviors.  And forcing non-standard behaviours usually leads to trouble in the long run.

Thanks for your respond.

For example VLAN 1 has a network 192.168.0.0 255.255.255.0 and I want to send a broadcast paquet to 192.168.1.255 (VLAN 2). 

Do you think that broadcast ip direct is the solution?? or how could achieve my target??

I think that I didn´t explain right before.

Regards.

Hellow

i have srx3400 chassis cluster and i want to add new configuration but i can't user mode configure.

this error from node :

warning: Clustering enabled; using private edit
Users currently editing the configuration:
root terminal p0 (pid 78400) on since 2016-04-28 09:46:58 UTC, idle 01:43:08
private [edit]
error: shared configuration database modified

Please temporarily use 'configure shared' to commit
outstanding changes in the shared database, exit,
and return to configuration mode using 'configure'

what should i do?

Thanks,

please try the below from primary.

root# commit synchronize force

Are you saying that you want the broadcast address of vlan 1 to be forwarded to vlan 2 in a different subnet and appear as the broadcast address of vlan 2 192.168.1.255?

Hi,

If I have a host in Vlan1 and I have 2 hosts in Vlan2, I want send one packet from host 1 to the theses host by broadcast (it is a summary of the network). 

I don´t know if I explained right.

Thanks.

Regards.

I check the different between 2 srx100, no differents. NAT is enable at ssg550 and SRX100 default enable NAT.

Lfetime settings on phase 2 also match between the SSG550 and SRX100. Phase2 message on ssg550 as follow.

Moreover I have tryed the bridge domain Vlan Although I have not lucky. I think that this operation is only to Switchs becouse I have the next code 

interfaces {
    fe-0/0/0 {
        unit 0 {
            family inet {
                dhcp;
            }
        }
    }
    fe-0/0/1 {
        unit 0 {
            family ethernet-switching {
                port-mode access;
                vlan {
                    members vlan16;
                }
            }
        }
    }
    fe-0/0/2 {
        unit 0 {
            family ethernet-switching {
                port-mode access;
                vlan {
                    members vlan10;
                }
            }
        }
    }
    fe-0/0/3 {
        unit 0 {
            family ethernet-switching {
                port-mode access;
                vlan {
                    members vlan16;
                }
            }
        }
    }
    fe-0/0/4 {
        unit 0 {
            family ethernet-switching {
                port-mode access;
            }
        }
    }
    fe-0/0/5 {
        unit 0 {
            family ethernet-switching {
                port-mode access;
            }
        }
    }
    fe-0/0/6 {
		encapsulation ethernet-bridge;
        unit 0 {
			family bridge;
                    }
    }
    fe-0/0/7 {
        unit 0 {
            family ethernet-switching {
                port-mode trunk;
                vlan {
                    members all;
                }
            }
        }
    }
    vlan {
        unit 2 {
            family inet {
                targeted-broadcast;
                address 192.168.15.254/23;
            }
        }
        unit 10 {
            family inet {
                targeted-broadcast;
                address 192.168.1.254/23;
            }
        }
        unit 11 {
            family inet {
                targeted-broadcast;
                address 192.168.3.254/23;
            }
        }
        unit 12 {
            family inet {
                targeted-broadcast;
                address 192.168.5.254/23;
            }
        }
        unit 13 {
            family inet {
                targeted-broadcast;
                address 192.168.7.254/23;
            }
        }
        unit 16 {
            family inet {
                targeted-broadcast;
                address 192.168.13.254/23;
            }
        }
        unit 17 {
            family inet {
                targeted-broadcast;
                address 192.168.17.254/23;
            }
        }
	}
	irb {
		unit 100 {
			family inet {
			address 192.168.11.254/23;
			}
		}
		unit 200 {
			family inet {
			address 192.168.9.254/23;
			}
		}
	}		

    
}
protocols {
    stp;
}
security {
    screen {
        ids-option untrust-screen {
            icmp {
                ping-death;
            }
            ip {
                source-route-option;
                tear-drop;
            }
            tcp {
                syn-flood {
                    alarm-threshold 1024;
                    attack-threshold 200;
                    source-threshold 1024;
                    destination-threshold 2048;
                    timeout 20;
                }
                land;
            }
        }
    }
    
    policies {
        from-zone Internet to-zone Monitoring {
            policy All_Internet_Monitoring {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone Monitoring to-zone Internet {
            policy All_Monitoring_Internet {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone Monitoring to-zone Monitoring {
            policy All_Monitoring_Monitoring {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone Monitoring {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                vlan.10 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
                vlan.11 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
                vlan.12 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
                vlan.13 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
                
                vlan.16 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
                vlan.17 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
                fe-0/0/7.0 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
				fe-0/0/6.0 {
                    host-inbound-traffic {
                        system-services {
                            all;
                        }
                        protocols {
                            all;
                        }
                    }
                }
            }
        }
        security-zone Internet {
            host-inbound-traffic {
                system-services {
                    ping;
                    http;
                    https;
                }
            }
            interfaces {
                fe-0/0/0.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                            dhcp;
                            https;
                            http;
                        }
                    }
                }
            }
        }
    }
}


vlans {
    default {
        l3-interface vlan.17;
    }
    vlan10 {
        vlan-id 10;
        l3-interface vlan.10;
    }
    vlan11 {
        vlan-id 11;
        l3-interface vlan.11;
    }
    vlan12 {
        vlan-id 12;
        l3-interface vlan.12;
    }
    vlan13 {
        vlan-id 13;
        l3-interface vlan.13;
    }
    vlan16 {
        vlan-id 16;
        l3-interface vlan.16;
    }
    vlan2 {
        vlan-id 2;
        l3-interface vlan.2;
    }
}

bridge-domains {

	vlan14 {
			
			vlan-id 14;
			routing-interface irb.100;
		}
    vlan15 {
	
		vlan-id 15;
        interface fe-0/0/6.0;
		routing-interface irb.200;
    }
}

and I have received the next message

There were error(s) delivering the configuration.

Error(s):
'unit 0, unit 0'

1) interface needs to be in a bridge-domain to support family bridge
2) Bridge family cannot be configured in route mode or for an interface with inet family
3) configuration check-out failed

I have used the next page,

http://networkengineering.stackexchange.com/questions/3709/adding-a-simple-vlan-on-a-juniper-mx

I am sure that I have done any wrong (Concept, code ...)

Thanks.

Regards.

I located a kb article on this message that seems to match your scenario.  since you are already running 6.2 it looks like you should try setting the soft life timer on the SSG550

the workaround for this issue is configure a different soft life timer on both 
of the peer devices:

set ike soft-lifetime-buffer <seconds>

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

I'm still not sure I understand, but it is sounding like you are looking for non-standard packet handling behavior.

A broadcast packet is generated by an application to a destination address that is the broadcast address for the assigned subnet and mask.  192.168.0.255 in your vlan1 above.

The switch will flood this to the entire broadcast domain just as the packet exists.

Devices will accept and read that packet and any application looking for broadcast traffic for that subnet will respond accordingly

If you create a bridge domain and bridge your vlan1 and vlan2, the vlan2 devices will see this broadcast packet addressed to 192.168.0.255 but will ignore the packet because the configured subnet on that vlan2 device is 192.168.1.x looking only for broadcast packets of 192.168.1.255

All the bridge domain does is allow the broadcast packet 192.168.0.255 to flood to all the connected devices.  This will NOT change the destiniation address to the other broadcast addresses you are bridging togther.  You would need some kind of packet manipulation and rewrite to do that.

Anyway, the reason your bridge domains are not connected is that you have created two separate bridge domains for your two vlans.  If you do need to bridge the vlans into a single broadcast domain you create only one bridge domain and place both vlans and all the desired layer 2 interfaces into the bridge.

The IRB interface is only needed if you require a layer 3 interface in the bridge domain.  You could still create your layer 3 interfaces using family inet on your physical interfaces on the SRX if you prefer.

Thanks for your respond,

ok I understand your clarification, thank you very much.

The issue is that I was looking for the bridge domain because you told me that I could introude 2 vlans in the same broadcast domain. Then I can have 2 vlan in the same broadcast but If I send a packet with 192.168.1.255, it won´t arrive to vlan 1 (I have understand it)

If one device in vlan the vlan 10 will transmmit (trought interface 2 for example) a broadcast packet with the address 192.168.1.255, my question is the next.

Can I do anything to arrive this packet throught the interface 7 (it is a trunk interface) without Router drops action??? Becouse the router close the broadcast domain..

I don´t know if you can understannd me.

Thanks.

Regards.

Hi rsuraj,

Many thanks

Hello,

On ISG devices, you unet vsd 0. Create multiple VSDs in such a way that some are active of one node while other are active on another node.

On SRX devices, when you create a reth interface, you bind it to RG group. You can create multiple RGs and depending upon its priority it will be active on different nodes. This is a basic desing though which utilizes data plane active active behavior.

Regards,

Rushi

There are two parts to how this packet handling works once the packet is on the network from your software.

1-the generated broadcast packet flooding to all your VLANs

The bridge domain solves this problem.  When you put multiple vlans or ports into a bridge domain they become one broadcast domain.  A broadcast packet will be flooded to all members in the bridge domain.

The normal usage of a bridge domain is when you have multiple vlans that arrive from different parts of the network that are tagged with different vlan-id or remote interfaces but really are devices in the same ip address subnet.  So we join these disparate vlans together in a bridge domain.

2-The device itself seeing that packet as a broadcast packet for itself

The device only recogonizes as a broadcast the packet for the actual subnet that the device has configured as an ip address on the device.  So even it sees a broadcast packet fro anohter subnet it will not respond to this packet.