Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - signal15

Pages: [1] 2 3 4 5 6 ... 8
1
Suggestions/Feedback / Testing
« on: November 15, 2017, 11:53:13 am »
Test

2
JunoSpace / Is anyone else here using Space?
« on: February 09, 2014, 07:03:01 pm »
I've done a couple of installs of it to manage SRX clusters.  It works well, I like the policy management much better than NSM.

Anyone else using it?  Experiences?

3
SRX Platform and J-series / Address objects based on DNS name
« on: June 28, 2012, 01:03:04 pm »
I'm converting a policy from ScreenOS to SRX.  It has a lot of objects that are DNS name based.  How does this perform on the SRX?  Am I going to see performance issues as it performs the lookups?

4
NetScreen and SSG/ISG Series Firewalls / Policy merging - scripts?
« on: June 05, 2012, 02:00:40 pm »
Say I have two firewalls that I want to merge into one.  As an example, say I have a prod firewall and a dev firewall.  They are connected by a link in the "Transit" zone.  I have rules on the prod firewall which grant access to dev resources via "DMZ->Transit" policies.  On the dev firewall, a corresponding Transit->dev-DMZ rule exists.  If I replace both firewalls with a single firewall and merge the policies, then I will need a single DMZ->dev-DMZ rule.

Does anyone know of a good automated way to do this?  The NSM policy merge tool doesn't seem to take this into account.

A script would need to determine what source and destination zone the objects were in, and change the rule appropriately. You may also run into situations where the destination zone is Transit on the first firewall, but the objects specified are actually in multiple zones on the dev firewall. 

Does anyone have a script to do this?  Or, any suggestions on existing scripts that could be modified rather than writing something from scratch?

5
Suggestions/Feedback / Status of our spam efforts
« on: December 20, 2011, 07:44:31 pm »
We are shutting down roughly 700-1000 spammers per day who attempt to register to the site.  Occasionally, we'll have one or two slip in though.  I've noticed recently that some of them are actually posting semi-relevant replies, and then putting links in their signature.

PLEASE report these users if you see this practice so we can delete them.

6
Routers / Your IPV6 plans
« on: October 10, 2011, 12:32:07 pm »
After you vote, please elaborate at where you are in the process, and any drivers behind it.  Looking for real world data.

7
Suggestions/Feedback / Mobile browsing enabled through Tapatalk
« on: September 18, 2011, 12:36:31 pm »
Just install the Tapatalk app from your respective app store, and search for JuniperForum.

8
Has anyone here done it?  How did you go about it?  I'm wondering what the proper way is to create the certs and the proper things to put in the setup screen for the certificate auth server built into the SA.  I have my own CA.

10
I have upgraded to the latest version of the forum software.  Due to a bug in one of the php files, someone was able to add some javascript which attempted to load malware to users running outdated versions of IE.  The server itself was NOT compromised.

The file that allowed this was in a mod, and it really wasn't being used.  I'm keeping the forum fairly stripped down this time and only installing mods that I really need (such as spam prevention, etc). 

Also, we're on a new server which is much beefier than the old one.   I'm making some additional changes to reduce spam and doing some security enhancements.  If you notice any problems with the new setup, post them in this thread.

11
If I set packet-mode, the SRX will pass the IPV6 traffic, but then it's not subject to inspection by the security policy and it just routes it.  I set up a routed /64 last night using packet mode, and was able to get full access to the machines on the inside even though the policy explicitly denied it.

When I set it to flow mode, it will not pass IPV6 traffic over the ip-0/0/0 tunnel interface (but can still ping IPV6 hosts on the inside). 

Looks like some people say it works in 10.3R2.  I'm on 10.3R3, and was on 10.2R3 and it didn't work there either.  Apparently it's broken in 10.4 also.  And the release notes tell you to read the security configuration guide to find out the limitations for it, so I can't find any documentation on what is and isn't broken.  Annoying.

Any idea why flow mode would break IPV6 traffic over an ip-x/x/x tunnel interface?


12
Routers / commit fails with next-table routes between two routing instances
« on: February 21, 2011, 12:56:42 am »
Code: [Select]
admin@signal15-fw# show routing-options
rib inet6.0 {
    static {
        route ::/0 next-hop 2001:470:1f10:d0d::1;
        route 2001:470:c111:1::/64 next-table trust-vr.inet6.0;
    }
}
router-id 10.129.1.1;

[edit]
admin@signal15-fw# show routing-instances
trust-vr {
    instance-type virtual-router;
    interface ge-0/0/0.0;
    interface st0.1;
    routing-options {
        rib trust-vr.inet6.0 {
            static {
                route ::/0 next-table inet6.0;
            }
        }
        static {
            route 10.128.0.0/22 {
                next-hop st0.1;
                retain;
            }
            route 0.0.0.0/0 next-table inet.0;
            route 192.168.150.0/24 next-hop st0.1;
            route 10.64.0.0/16 next-hop st0.1;
            route 10.64.1.0/24 next-hop st0.1;
            route 10.129.128.0/24 next-hop 10.129.1.4;
        }
        auto-export {
            disable;
        }
    }
    protocols {
        ospf {                          
            enable;
            area 0.0.0.0 {
                area-range 10.0.0.0/8;
                interface ge-0/0/0.0 {
                    passive;
                }
                interface st0.1;
            }
        }
    }
}

[edit]
admin@signal15-fw# commit
error: [rib inet6.0 routing-options static]
    next-table may loop
error: configuration check-out failed

The ipv6 next-table routes are what's causing the problem.  I have routes between inet6.0 and trust-vr.inet6.0.  I understand that you could do something dumb and make a loop, but this clearly will not loop.  This should be a valid configuration.  Unless I'm missing something?  I don't see any other way to do this.

I have a /64 on the outside of the device, routing to another /64 on the inside (soon to be several /64's).  I know I could do away with the separate routing instance, but I need it for some other things (as annoying as it is on JunOS as compared to ScreenOS).  BTW, ScreenOS never prevented me from doing things like this.

It will throw the same error message if you do it with ipv4, so it's not ipv6 specific.

13
Suggestions/Feedback / Forum updates
« on: October 26, 2010, 03:52:07 pm »
I did some updates:

  • removed the several thousand spam messages that we were bombarded with, and deleted all of the associated accounts.
  • added reCAPTCHA support, so hopefully this will keep the bots from registering and posting.
  • consolidated all of the ScreenOS related boards into the Netscreen/SSG/ISG board.  There were just too many boards going on, and I think it will make discussion a bit easier.
  • updated the Juniper logo in the top right
  • did some various renaming and changing of board descriptions

I also updated the Marketplace board description to explicitly forbid commercial postings for free.  I'm paying for the hardware and hosting out of pocket, and advertising isn't covering everything.  If you're making money selling here, then throw a few schillings our way.  I need a new server to host this on, as the one that it's on now is an *old* IBM server with a failed disk in it (yes, I do regular backups).  If anyone has a decent server laying around doing nothing, I'd be happy to pay for shipping and get it out of there. 

Also, if any regular posters/users are interested in having moderator privs to delete spam and such, PM me.  I don't always have time to log into the site on a regular basis and check things out.

Personally, I still think there are more boards than what I would like.  If anyone has any suggestions on consolidating more of them or reordering them more logically, then I'm all ears.

14
SRX Platform and J-series / Destination NAT for GRE on SRX
« on: October 21, 2009, 04:32:34 pm »
Is this not possible?  When I go to create the nat rule, the only available options are source ip and destination ip/port.  There is no way to match on IP Type 47.

Any ideas, or is this a limitation?

16
Suggestions/Feedback / Test post
« on: September 26, 2009, 04:53:37 pm »
Upgrades and maintenance.

17
Suggestions/Feedback / Forum organization suggestions?
« on: May 18, 2009, 03:00:50 pm »
J-series and SRX platforms are very similar from an operational standpoint now.  Should these be combined into a single forum called JUNOS Flow Mode software or something similar?

I'm also thinking it might make sense to combine all of the ScreenOS topics into a single section. 

Would it make sense to lump anything that runs JUNOS into a single section?  This is a lot of different products, but they all have overlapping functionality.  If someone needs help configuring BGP on an SRX, a BGP wizard browsing the Routers section might not even see the post. 

When I created this forum, I made sure to keep as few sections as possible to help spur discussion on topics, but Juniper's product line has grown to a point where this isn't really feasible unless I start lumping devices with similar functionality together.

Thoughts?

18
Switches / Weird behavior with igmp-snooping
« on: May 18, 2009, 02:46:05 pm »
I have a surveillance camera that floods the network with RTP packets destined to a multicast address.  It was flooding the whole local LAN, so I enabled IGMP snooping globally.  This stopped the flooding, and traffic would only be sent to hosts that requested it.  However, I noticed that on some ports, I was seeing unicast traffic destined for other hosts, behavior more like a hub.

Also, a continuous ping to any host on the network would have its latency increase with each ping until after about 15 pings or so I was getting 80-90% packet loss.  I disabled IGMP snooping and the multicast video stream on the camera, and things went back to normal.

This is on an EX-4200.

Did I forget to do something?

19
SRX Platform and J-series / Bugs in 9.4R1.8
« on: March 11, 2009, 03:14:13 pm »
I don't have support on the J-6350 I'm testing with, so hopefully someone from Juniper will see this thread and try to reproduce the problems.  I'll update this as I find problems, or remove items if someone can tell me that these were stupid mistakes.

- Assigning an st0.X interface to a VPN tunnel causes device lockup a few seconds after commit.  Power cycle required.
- IPSec config in the web interface only allows the user to select st0 for the tunnel interface, not st0.X
- Setting up a DHCP pool to send out option 66 results in an error that says to use the boot-server option instead.  The boot server option only supports an IP, not a full URL like some IP phones require (e.g. "ftp://polycom:password@10.1.1.1")
- When configuring an interface in the non-default routing instance to obtain an address through DHCP, the default route provided by the DHCP server is not inserted into the routing table.

20
When attempting to configure a DHCP client on a vlan interface like this:

Code: [Select]
set interfaces vlan.100 family inet dhcp
A commit spawns an error that says I can only set up the DHCP client on a physical ethernet interface.  Why does this even matter?  A VLAN interface with family inet configured gets its own MAC address.  Shouldn't be a problem.

Also, it appears that if I set up a trunk between a J-series ES router and an EX switch, that any vlan.X interfaces with L3 addresses on the J-series are not available over the trunk from hosts on the switch.  The only way to make it work is to assign the L3 address to a tagged logical unit on the physical interface. This is annoying.  Can anyone else confirm this behavior?

I also read that link aggregation is not supported on the built in ports on the J-series.  But it lets me configure it, and the link appears to be up.  What is the real story on this?  None of the Juniper engineers I spoke with knew much about it and were surprised that it even let me configure it.  I have not tried sending traffic over it yet, but the ae0 interface is up/up on both ends.

Pages: [1] 2 3 4 5 6 ... 8