Re: [j-nsp] SRX Source NAT internal users to two or more public IPs

[William McLendon]

I think I may have been able to answer my own question.  I stumbled across this 
KB article which I think spells it out pretty well:

http://kb.juniper.net/KB20711



On Jul 18, 2013, at 2:04 PM, William McLendon  wrote:

> hi all,
> 
> We have an issue where we have enough internal users and sessions using the 
> general outbound NAT that we are hitting the session limit for the single 
> public IP due to running out of ports. (really its due to how Source NAT is 
> carved up on an HA pair…see http://kb.juniper.net/KB14958 )
> 
> However I think if just add additional IPs to NAT the users to, it may end up 
> breaking some applications as they establish a new outbound session from 
> clicking a URL or something, but that session gets NAT'd to the other IP that 
> the far side is not expecting to see it from.
> 
> I think ScreenOS had something called Sticky DIP that could help mitigate 
> this where for some NAT Timer, any session initiated by an IP address would 
> always be NAT'd to the same public IP -- does SRX have a similar feature?  If 
> not, I think my only other option then would be to carve up the internal 
> networks, ie 10.10.10/24 NATs to public IP A, and 11.11.11.0/24 NATs to 
> public IP B, etc. which is probably ok, but can get a little cumbersome.
> 
> Or if anyone knows another way please share :)
> 
> Thanks,
> 
> Will

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Source NAT internal users to two or more public IPs

[huy phuong]

you can using persistent-nat like kb below:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB21296

regards,

Phuong


On Fri, Jul 19, 2013 at 1:04 AM, William McLendon wrote:

> hi all,
>
> We have an issue where we have enough internal users and sessions using
> the general outbound NAT that we are hitting the session limit for the
> single public IP due to running out of ports. (really its due to how Source
> NAT is carved up on an HA pair…see http://kb.juniper.net/KB14958 )
>
> However I think if just add additional IPs to NAT the users to, it may end
> up breaking some applications as they establish a new outbound session from
> clicking a URL or something, but that session gets NAT'd to the other IP
> that the far side is not expecting to see it from.
>
> I think ScreenOS had something called Sticky DIP that could help mitigate
> this where for some NAT Timer, any session initiated by an IP address would
> always be NAT'd to the same public IP -- does SRX have a similar feature?
>  If not, I think my only other option then would be to carve up the
> internal networks, ie 10.10.10/24 NATs to public IP A, and 11.11.11.0/24NATs 
> to public IP B, etc. which is probably ok, but can get a little
> cumbersome.
>
> Or if anyone knows another way please share :)
>
> Thanks,
>
> Will
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multiple flow-servers with inline jflow on MX80

[Richard Hesse]

So 1 collector is actually 1 flow server? I read the documentation and it
says 1 instance -- which I took to mean address family. I can understand
having only a single collection instance, but it also seems logical to have
multiple flow servers defined in that instance.

I can get around this with UDP replication strategies, I just would prefer
to do it natively.

-richard


On Thu, Jul 18, 2013 at 11:58 PM,  wrote:

> For any of your MX-series router the limitations are :
> - IPFIX (RFC 5101): inline J-flow supported on MPC only => 1 collector only
> - Note that only J-flow v5 and v8 are supported on RE => 8 collectors
> (same for MS-DPC)
>
>
>
> -Message d'origine-
> De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part
> de Richard Hesse
> Envoyé : vendredi 19 juillet 2013 00:27
> À : juniper-nsp@puck.nether.net
> Objet : [j-nsp] Multiple flow-servers with inline jflow on MX80
>
> Does anyone know if it's possible to define multiple flow-servers when
> doing inline jflow on a MX80? I know it's possible with RE-based sampling,
> but I can't see anything in the docs regarding inline jflow.
>
> I tried adding another flow-server but got this failure:
>
>   cflowd configuration error
> instance "'sample-jflow" family "inet", cannot configure more than 1
> ipfix collectors
>
> A single flow-server here works fine, but I might be missing something
> special for multiple servers:
>
> flow-server X.X.X.X {
> port 9993;
> autonomous-system-type origin;
> version-ipfix {
> template {
> ipv4;
> }
> }
> }
> flow-server X.X.X.Y {
> port 9993;
> autonomous-system-type origin;
> version-ipfix {
> template {
> ipv4;
> }
> }
> }
> inline-jflow {
> source-address Y.Y.Y.Y;
> }
>
> TIA,
> -richard
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Source NAT internal users to two or more public IPs

[Graham Brown]

Hi Will,

You have a couple of options on the SRX platform to do this, however I
think 'Source address NAT + address-persistent' would be the best option
for you - as long as ports are available then a source will always be
translated to the same IP address.

The following KB article sums the types of NAT up nicely:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB20711

HTH,
Graham

On 19 July 2013 06:04, William McLendon  wrote:

> hi all,
>
> We have an issue where we have enough internal users and sessions using
> the general outbound NAT that we are hitting the session limit for the
> single public IP due to running out of ports. (really its due to how Source
> NAT is carved up on an HA pair…see http://kb.juniper.net/KB14958 )
>
> However I think if just add additional IPs to NAT the users to, it may end
> up breaking some applications as they establish a new outbound session from
> clicking a URL or something, but that session gets NAT'd to the other IP
> that the far side is not expecting to see it from.
>
> I think ScreenOS had something called Sticky DIP that could help mitigate
> this where for some NAT Timer, any session initiated by an IP address would
> always be NAT'd to the same public IP -- does SRX have a similar feature?
>  If not, I think my only other option then would be to carve up the
> internal networks, ie 10.10.10/24 NATs to public IP A, and 11.11.11.0/24NATs 
> to public IP B, etc. which is probably ok, but can get a little
> cumbersome.
>
> Or if anyone knows another way please share :)
>
> Thanks,
>
> Will
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Graham Brown
Twitter - @mountainrescuer 
LinkedIn 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Fwd: Re: BGP Multipath

[Keith]

Thanks for the all the replies.

We actually do some local-pref on some other upstreams for outbound but 
discovered a small
wrinkle
in that the new connection uses a different bgp auth key so I have to create a 
new bgp
group to handle this
connection.

So a new question arises, can I use existing import/export policy that is used 
on one bgp
group already on
a new one?

My SRX240 (one of my lab devices) doesn't complain and my neighbors come up 
when I
configure it on the
lab stuff so I'm guessing our MX wont have a problem either.

Thanks,
Keith



On 7/18/2013 6:22 PM, Payam Chychi wrote:

Many ways to skin a cat... personally i would use local pref for outbound and 
as-prepend
on the inbound and your golden

--
Payam Chychi
Network Engineer / Security Specialist

On Thursday, 18 July, 2013 at 4:45 PM, Tim Vollebregt wrote:


Hi Keith,

Yes, this sounds good. But to have the inbound/outbound traffic on the new 10GE 
link
you will have to influence the path selection on both import and export 
policies.

A good way to do this is:

import policy:

set policy-options policy-statement upstream-in term 1GE from neighbor 1.1.1.1
set policy-options policy-statement upstream-in term 1GE then metric 1000
set policy-options policy-statement upstream-in term 1GE then accept
set policy-options policy-statement upstream-in term 10GE from neighbor 2.2.2.2
set policy-options policy-statement upstream-in term 10GE then metric 1
set policy-options policy-statement upstream-in term 10GE then accept

Of course this is just an example, you can use either accept or next policy and 
all
other flavors of routing decision/filtering.

export policy:

set policy-options policy-statement upstream-out term 1GE to neighbor 1.1.1.1
set policy-options policy-statement upstream-out term 1GE then metric 1000
set policy-options policy-statement upstream-out term 1GE then accept
set policy-options policy-statement upstream-out term 10GE to neighbor 2.2.2.2
set policy-options policy-statement upstream-out term 10GE then metric 1
set policy-options policy-statement upstream-out term 10GE then accept

Hopefully the upstream will honor the metrics you are setting on the outbound 
policy.
Afterwards you can verify if all traffic moves from the 1GE to the 10GE port 
and when
all is gone you can safely remove the 1GE neighbor statement(s).

Good luck.

Tim


On Jul 19, 2013, at 1:10 AM, Keith wrote:


We recently just turned up another connection to one of our upstreams, so now 
we have
two. One is a GE the other is a 10GE.

We are getting into new territory here.

The GE connection is in use and working fine.

These two connections home to two different routers on our upstream.

As the BGP policy will remain the same, I was just going to add a new neighbour
statement to that
particular BGP group for that upstream.

I was told to also add multipath to that as well if I want to use both 
connections for
load balancing.

Don't really want to use both as the GE will be going away sometime, but to 
make sure
it works I was
going to add the new neighbor IP address, make sure BGP comes up and traffic is 
there
then remove the old neighbor
IP address.





___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Source NAT internal users to two or more public IPs

[Klaus Groeger]

Hi


you search for persistent nat:
http://www.juniper.net/techpubs/software/junos-security/junos-security96/junos-security-swconfig-security/understand-persistent-nat-section.html


But configuring splitted src-NAT isn't
such a burden. Just go to your src-nat rulset
and insert a second rule, that covers 
the one half of your internal network via
the match statement. It's quite simple. 


If you need explicit help, post your config. 


Klaus
—
Sent from Mailbox for iPhone

On Fri, Jul 19, 2013 at 7:08 AM, William McLendon 
wrote:

> hi all,
> We have an issue where we have enough internal users and sessions using the 
> general outbound NAT that we are hitting the session limit for the single 
> public IP due to running out of ports. (really its due to how Source NAT is 
> carved up on an HA pair…see http://kb.juniper.net/KB14958 )
> However I think if just add additional IPs to NAT the users to, it may end up 
> breaking some applications as they establish a new outbound session from 
> clicking a URL or something, but that session gets NAT'd to the other IP that 
> the far side is not expecting to see it from.
> I think ScreenOS had something called Sticky DIP that could help mitigate 
> this where for some NAT Timer, any session initiated by an IP address would 
> always be NAT'd to the same public IP -- does SRX have a similar feature?  If 
> not, I think my only other option then would be to carve up the internal 
> networks, ie 10.10.10/24 NATs to public IP A, and 11.11.11.0/24 NATs to 
> public IP B, etc. which is probably ok, but can get a little cumbersome.
> Or if anyone knows another way please share :)
> Thanks,
> Will
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Source NAT internal users to two or more public IPs

[Alex Arseniev]

user@srx# help apropos address-persistent
set logical-systems  security nat source address-persistent
   Allow source address to maintain same translation
set security nat source address-persistent
   Allow source address to maintain same translation

HTH
Thanks
Alex

- Original Message - 
From: "William McLendon" 

To: 
Sent: Thursday, July 18, 2013 7:04 PM
Subject: [j-nsp] SRX Source NAT internal users to two or more public IPs


hi all,

We have an issue where we have enough internal users and sessions using the 
general outbound NAT that we are hitting the session limit for the single 
public IP due to running out of ports. (really its due to how Source NAT is 
carved up on an HA pair…see http://kb.juniper.net/KB14958 )


However I think if just add additional IPs to NAT the users to, it may end 
up breaking some applications as they establish a new outbound session from 
clicking a URL or something, but that session gets NAT'd to the other IP 
that the far side is not expecting to see it from.


I think ScreenOS had something called Sticky DIP that could help mitigate 
this where for some NAT Timer, any session initiated by an IP address would 
always be NAT'd to the same public IP -- does SRX have a similar feature? 
If not, I think my only other option then would be to carve up the internal 
networks, ie 10.10.10/24 NATs to public IP A, and 11.11.11.0/24 NATs to 
public IP B, etc. which is probably ok, but can get a little cumbersome.


Or if anyone knows another way please share :)

Thanks,

Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Source NAT internal users to two or more public IPs

[Klaus Groeger]

Sry, wrong link, here's the correct one
http://www.juniper.net/techpubs/software/junos-security/junos-security96/junos-security-swconfig-security/configuring-persistent-address-pool-example.html#configuring-persistent-address-pool-example
—
Sent from Mailbox for iPhone

On Fri, Jul 19, 2013 at 7:08 AM, William McLendon 
wrote:

> hi all,
> We have an issue where we have enough internal users and sessions using the 
> general outbound NAT that we are hitting the session limit for the single 
> public IP due to running out of ports. (really its due to how Source NAT is 
> carved up on an HA pair…see http://kb.juniper.net/KB14958 )
> However I think if just add additional IPs to NAT the users to, it may end up 
> breaking some applications as they establish a new outbound session from 
> clicking a URL or something, but that session gets NAT'd to the other IP that 
> the far side is not expecting to see it from.
> I think ScreenOS had something called Sticky DIP that could help mitigate 
> this where for some NAT Timer, any session initiated by an IP address would 
> always be NAT'd to the same public IP -- does SRX have a similar feature?  If 
> not, I think my only other option then would be to carve up the internal 
> networks, ie 10.10.10/24 NATs to public IP A, and 11.11.11.0/24 NATs to 
> public IP B, etc. which is probably ok, but can get a little cumbersome.
> Or if anyone knows another way please share :)
> Thanks,
> Will
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Source NAT internal users to two or more public IPs

[Muhammad Atif Jauhar]

Hi William,

Similar to Sticky DIP, there are two terminologies address shifting and
address persistence in SRX.

1. In address persistence. Junos OS will use the same source IP address for
different traffic types associated with the same source host. To ensure the
use of the same address, configure the address-persistent global source NAT

2. (Best option) In address shifting, this type of translation is
one-to-one, static, and without PAT. If the original source address range
is larger than the address range in the user-defined pool, packets might
drop

Regards,
Atif.


On Thu, Jul 18, 2013 at 9:04 PM, William McLendon wrote:

> hi all,
>
> We have an issue where we have enough internal users and sessions using
> the general outbound NAT that we are hitting the session limit for the
> single public IP due to running out of ports. (really its due to how Source
> NAT is carved up on an HA pair…see http://kb.juniper.net/KB14958 )
>
> However I think if just add additional IPs to NAT the users to, it may end
> up breaking some applications as they establish a new outbound session from
> clicking a URL or something, but that session gets NAT'd to the other IP
> that the far side is not expecting to see it from.
>
> I think ScreenOS had something called Sticky DIP that could help mitigate
> this where for some NAT Timer, any session initiated by an IP address would
> always be NAT'd to the same public IP -- does SRX have a similar feature?
>  If not, I think my only other option then would be to carve up the
> internal networks, ie 10.10.10/24 NATs to public IP A, and 11.11.11.0/24NATs 
> to public IP B, etc. which is probably ok, but can get a little
> cumbersome.
>
> Or if anyone knows another way please share :)
>
> Thanks,
>
> Will
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Regards,

Muhammad Atif Jauhar
(+966-56-00-04-985)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP Multipath

[Payam Chychi]

Many ways to skin a cat... personally i would use local pref for outbound and 
as-prepend on the inbound and your golden 

-- 
Payam Chychi
Network Engineer / Security Specialist


On Thursday, 18 July, 2013 at 4:45 PM, Tim Vollebregt wrote:

> Hi Keith,
> 
> Yes, this sounds good. But to have the inbound/outbound traffic on the new 
> 10GE link you will have to influence the path selection on both import and 
> export policies.
> 
> A good way to do this is:
> 
> import policy:
> 
> set policy-options policy-statement upstream-in term 1GE from neighbor 1.1.1.1
> set policy-options policy-statement upstream-in term 1GE then metric 1000
> set policy-options policy-statement upstream-in term 1GE then accept
> set policy-options policy-statement upstream-in term 10GE from neighbor 
> 2.2.2.2
> set policy-options policy-statement upstream-in term 10GE then metric 1
> set policy-options policy-statement upstream-in term 10GE then accept
> 
> Of course this is just an example, you can use either accept or next policy 
> and all other flavors of routing decision/filtering.
> 
> export policy:
> 
> set policy-options policy-statement upstream-out term 1GE to neighbor 1.1.1.1
> set policy-options policy-statement upstream-out term 1GE then metric 1000
> set policy-options policy-statement upstream-out term 1GE then accept
> set policy-options policy-statement upstream-out term 10GE to neighbor 2.2.2.2
> set policy-options policy-statement upstream-out term 10GE then metric 1
> set policy-options policy-statement upstream-out term 10GE then accept
> 
> Hopefully the upstream will honor the metrics you are setting on the outbound 
> policy. Afterwards you can verify if all traffic moves from the 1GE to the 
> 10GE port and when all is gone you can safely remove the 1GE neighbor 
> statement(s).
> 
> Good luck.
> 
> Tim
> 
> 
> On Jul 19, 2013, at 1:10 AM, Keith wrote:
> 
> > We recently just turned up another connection to one of our upstreams, so 
> > now we have two. One is a GE the other is a 10GE.
> > 
> > We are getting into new territory here.
> > 
> > The GE connection is in use and working fine.
> > 
> > These two connections home to two different routers on our upstream.
> > 
> > As the BGP policy will remain the same, I was just going to add a new 
> > neighbour statement to that
> > particular BGP group for that upstream.
> > 
> > I was told to also add multipath to that as well if I want to use both 
> > connections for load balancing.
> > 
> > Don't really want to use both as the GE will be going away sometime, but to 
> > make sure it works I was
> > going to add the new neighbor IP address, make sure BGP comes up and 
> > traffic is there then remove the old neighbor
> > IP address.
> > 
> > Would this be a sensible way to do it?
> > 
> > Thanks.
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > 
> 
> 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multiple flow-servers with inline jflow on MX80

[louis.poncin]

For any of your MX-series router the limitations are :
- IPFIX (RFC 5101): inline J-flow supported on MPC only => 1 collector only
- Note that only J-flow v5 and v8 are supported on RE => 8 collectors (same for 
MS-DPC)



-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de 
Richard Hesse
Envoyé : vendredi 19 juillet 2013 00:27
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] Multiple flow-servers with inline jflow on MX80

Does anyone know if it's possible to define multiple flow-servers when doing 
inline jflow on a MX80? I know it's possible with RE-based sampling, but I 
can't see anything in the docs regarding inline jflow.

I tried adding another flow-server but got this failure:

  cflowd configuration error
instance "'sample-jflow" family "inet", cannot configure more than 1 ipfix 
collectors

A single flow-server here works fine, but I might be missing something special 
for multiple servers:

flow-server X.X.X.X {
port 9993;
autonomous-system-type origin;
version-ipfix {
template {
ipv4;
}
}
}
flow-server X.X.X.Y {
port 9993;
autonomous-system-type origin;
version-ipfix {
template {
ipv4;
}
}
}
inline-jflow {
source-address Y.Y.Y.Y;
}

TIA,
-richard
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp