[c-nsp] How to prevent https facebook from the cisco router 1841
Hari bamsha Sapkota
sapkota.hari006 at gmail.com
Thu Nov 14 10:59:08 EST 2013
Hi Pablo,
The first option won't work for the HTTPs. Correct me if i'm wrong :)
I had tried for the second option before some months ago but I couldn't
accomplish it by blocking the IP found by nslookup since there are lots of
addresses for the site like Facebook & its not scalable as well.
If you have any additional information which I could be missing here,
please share that with us.
Thanks & regards,
Hari Sapkota
CCIE#38346
On Thu, Nov 14, 2013 at 9:25 PM, Pablo Lucena <plucena at coopergeneral.com>wrote:
> You can do something like this on a 1841:
>
> class-map match-any BLOCKED-WEBSITES
> match access-group name BLOCKED-WEBSITES-ACL
> match protocol http host "*facebook*"
>
> policy-map BLOCK_WEB
> class BLOCKED-WEBSITES
> drop
>
> int f0/0
> service-policy input BLOCK_WEB
>
> The ACL can also be used to match on specific IPs...you can do a nslookup
> on facebook.com and get the list of addresses that resolved. This can
> change though (as you know facebook has MANY addresses).
>
> Another fault with this is that it only matches on HTTP. If the user uses
> HTTPS then they can get through.
>
> A better option would be using OpenDNS (free!). You can block specific web
> pages, or entire categories of web pages. Then on your router you can set
> up filtering of outbound DNS traffic to any other DNS server besides the
> OpenDNS ones (to stop smart users that figure out that by changing their
> DNS server they can bypass the block).
>
>
> Pablo
>
> On Thu, Nov 14, 2013 at 10:02 AM, <cisco-nsp-request at puck.nether.net>
> wrote:
>
> > Send cisco-nsp mailing list submissions to
> > cisco-nsp at puck.nether.net
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > or, via email, send a message with subject or body 'help' to
> > cisco-nsp-request at puck.nether.net
> >
> > You can reach the person managing the list at
> > cisco-nsp-owner at puck.nether.net
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of cisco-nsp digest..."
> >
> >
> > Today's Topics:
> >
> > 1. [IOS XR] export to default-vrf (Catalin Petrescu)
> > 2. Re: [IOS XR] export to default-vrf (Oliver Boehmer (oboehmer))
> > 3. Re: 7600 10GE card recommendations (1 & 2 port cards)
> > (James Bensley)
> > 4. Re: [IOS XR] export to default-vrf (Catalin Petrescu)
> > 5. Re: Effect of simultaneous TCP sessions on bandwidth (Tom Storey)
> > 6. Re: How to prevent https facebook from the cisco router 1841
> > (A.L.M.Buxey at lboro.ac.uk)
> > 7. Re: How to prevent https facebook from the cisco router 1841
> > (Doug McIntyre)
> > 8. Re: [IOS XR] export to default-vrf (Catalin Petrescu)
> > 9. Re: nexus-switche issues no arp-requests (Oswald, Thomas)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 14 Nov 2013 10:36:45 +0200
> > From: Catalin Petrescu <cpmarvin at gmail.com>
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] [IOS XR] export to default-vrf
> > Message-ID:
> > <CAP=_-
> > 9Nqqp9XVsxZw_dbFJ9UGF_b0Uxjr7Vtc9bonRu_dxRdfw at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hi all,
> >
> > Did anyone get this to work on XR 4.3.2.
> >
> > vrf TEST
> > address-family ipv4 unicast
> > export to default-vrf route-policy default_policy_pass_all
> >
> > route-policy default_policy_pass_all
> > pass
> > end-policy
> >
> > router bgp
> >
> > vrf TEST
> > rd 1:1
> > address-family ipv4 unicast
> > redistribute connected metric 10
> > redistribute static metric 10
> >
> > RP/0/RSP1/CPU0:#sh route vrf TEST
> > ....
> > B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
> > 17:54:43
> >
> > RP/0/RSP1/CPU0:#sh route 99.99.99.1
> > Thu Nov 14 03:34:31.038 EET
> >
> > % Network not in table
> >
> > the goal is to get routers ( 99.99.99.1/32) from vrf TEST in grt (
> > defaul-vrf) .
> >
> > Thx,
> >
> > Catalin Petrescu
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Thu, 14 Nov 2013 09:07:36 +0000
> > From: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
> > To: Catalin Petrescu <cpmarvin at gmail.com>, "cisco-nsp at puck.nether.net"
> > <cisco-nsp at puck.nether.net>
> > Subject: Re: [c-nsp] [IOS XR] export to default-vrf
> > Message-ID: <CEAA5035.6F35C%oboehmer at cisco.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> >
> > >Hi all,
> > >
> > >Did anyone get this to work on XR 4.3.2.
> > >
> > >vrf TEST
> > > address-family ipv4 unicast
> > > export to default-vrf route-policy default_policy_pass_all
> > >
> > >route-policy default_policy_pass_all
> > > pass
> > >end-policy
> > >
> > >[...]
> > >RP/0/RSP1/CPU0:#sh route vrf TEST
> > >....
> > >B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
> > >17:54:43
> >
> > is this an iBGP or an eBGP vrf route you are trying to export? Only
> > external or locally originated routes are candidates to be exported from
> a
> > VRF (anywhere, wether in global or into a different VRF), you need to do
> > this on the originating PE. This rule is there to avoid loops, similar to
> > standard BGP advertisement rule of only sending iBGP paths to external or
> > RR-client peers.
> >
> > oli
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Thu, 14 Nov 2013 09:42:05 +0000
> > From: James Bensley <jwbensley at gmail.com>
> > To: Nick Hilliard <nick at foobar.org>, "cisco-nsp at puck.nether.net"
> > <cisco-nsp at puck.nether.net>
> > Subject: Re: [c-nsp] 7600 10GE card recommendations (1 & 2 port cards)
> > Message-ID:
> > <
> > CAAWx_pXWiOrGM-1TLCjgj_Zjb6UncFs2ei_BjrUQJCH+A1KKBg at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hi Nick,
> >
> > Many thanks for the info, that is very useful :)
> >
> > I shall continue to research and include the Ws-X7604-10GE.
> >
> > Kind regards,
> > James.
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Thu, 14 Nov 2013 13:57:39 +0200
> > From: Catalin Petrescu <cpmarvin at gmail.com>
> > To: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
> > Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> > Subject: Re: [c-nsp] [IOS XR] export to default-vrf
> > Message-ID:
> > <CAP=_-
> > 9P+gCn+HZYpJ3fLaP8tuEf8e+5VvaedDGvQUQk+Ovo-UA at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > hi Oliver,
> >
> > In this case it's a iBGP route but i've tested with connected static and
> > ospf and it's the same.
> >
> > vrf RO_CASA
> > address-family ipv4 unicast
> > import route-target
> > 1:1
> > !
> > export to default-vrf route-policy default_policy_pass_all
> > export route-target
> > 1:1
> > !
> >
> > RP/0/RSP1/CPU0:#sh route vrf TEST
> > .....
> > C 10.10.100.0/24 is directly connected, 21:18:10, BVI1
> > L 10.10.100.200/32 is directly connected, 21:18:10, BVI1
> > C 10.200.200.0/24 is directly connected, 00:01:40, TenGigE0/0/1/3.200
> > L 10.200.200.1/32 is directly connected, 00:01:40, TenGigE0/0/1/3.200
> > B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
> > 21:15:11
> > L 192.168.1.1/32 is directly connected, 21:18:10, Loopback100
> > O 200.200.200.200/32 [110/2] via 10.200.200.200, 00:01:32,
> > TenGigE0/0/1/3.200
> >
> > RP/0/RSP1/CPU0:# sh route 10.10.100.0
> > Thu Nov 14 06:54:56.034 EET
> >
> > % Network not in table
> >
> > RP/0/RSP1/CPU0:#sh route 200.200.200.200
> > Thu Nov 14 06:55:02.156 EET
> >
> > % Network not in table
> >
> > Thx,
> >
> > Catalin
> >
> >
> >
> > On Thu, Nov 14, 2013 at 11:07 AM, Oliver Boehmer (oboehmer) <
> > oboehmer at cisco.com> wrote:
> >
> > >
> > > >Hi all,
> > > >
> > > >Did anyone get this to work on XR 4.3.2.
> > > >
> > > >vrf TEST
> > > > address-family ipv4 unicast
> > > > export to default-vrf route-policy default_policy_pass_all
> > > >
> > > >route-policy default_policy_pass_all
> > > > pass
> > > >end-policy
> > > >
> > > >[...]
> > > >RP/0/RSP1/CPU0:#sh route vrf TEST
> > > >....
> > > >B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
> > > >17:54:43
> > >
> > > is this an iBGP or an eBGP vrf route you are trying to export? Only
> > > external or locally originated routes are candidates to be exported
> from
> > a
> > > VRF (anywhere, wether in global or into a different VRF), you need to
> do
> > > this on the originating PE. This rule is there to avoid loops, similar
> to
> > > standard BGP advertisement rule of only sending iBGP paths to external
> or
> > > RR-client peers.
> > >
> > > oli
> > >
> > >
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Thu, 14 Nov 2013 13:08:45 +0000
> > From: Tom Storey <tom at snnap.net>
> > To: Youssef Bengelloun-Zahr <youssef at 720.fr>
> > Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> > Subject: Re: [c-nsp] Effect of simultaneous TCP sessions on bandwidth
> > Message-ID:
> > <
> > CAFDgZgUmqKSCMQjQ0w_uXUbyg4UTTV42vpdLx+uh2HC9JyLeNg at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > So if I understand this correctly, with two tests running, each test
> > only manages about 50% of the bandwidth of the link?
> >
> > Are these tests sending data in only one direction, or both?
> >
> > If they are sending data in both directions, would it not make sense
> > that each can only use about half the link? A sends ~50% to B which is
> > repeated back to A, and C sends ~50% to D which is repeated back to C.
> > That makes about 100% utilisation each way?
> >
> > Maybe I missed something...
> >
> > On 10 November 2013 21:26, Youssef Bengelloun-Zahr <youssef at 720.fr>
> wrote:
> > >
> > >
> > > Le 11 nov. 2013 ? 04:22, Randy <randy_94108 at yahoo.com> a ?crit :
> > >
> > >>
> > >>
> > >>>>> - TCP traffic hits some kind of limit and isn't able to
> achieve
> > more
> > >>>>> than 40-60 Mbits/s in average <=== That's the problem we are
> > facing
> > >>
> > >> what happens if you do this -
> > >>
> > >>
> > >> a transfer from host A(fra) to host B(ham) and another transfer at the
> > same time from host D(ham) to host C(fra)? Do still avg at 90M for each
> > transfer or do both drop to the 40M avg? If you pull off 90M it would
> > eliminate the link. If not; since you have enabled high performance
> > options, tcp timestamping used to calculate RTT perceives
> congenstion(with
> > the increase of traffic across link) and initiates slowstart.
> > >
> > > Hello,
> > >
> > > Funny you mention this :
> > >
> > > a- first, we start transfer from A (FRA) to B (HAM), we achieve BW
> close
> > to 90 mbits/s,
> > >
> > > b- second, we start transfer from B to A (while first transfer is
> > running) and BW for first transfer collapses.
> > >
> > >
> > >>
> > >> if what you are seeing only applies for simultanours transfers:
> > >>
> > >> A To B and B to A, It would seem to imply A and B are the bottlenecks.
> > >
> > > Hello, seems very unlikely to me :
> > >
> > > - At location A, we have a Brocade CER-RT acting as a PE delivering
> > Layer 2 service to the customer.
> > >
> > > Customer server is directly connected using a GigE port.
> > >
> > > - At location B, we have some kind of Alcatel CPE provided by LL
> > provider.
> > >
> > > Customer server is directly connected using a FE port.
> > >
> > > Thanks.
> > >
> > >
> > >
> > >>
> > >> hth,
> > >> ./Randy
> > >>
> > >
> > > _______________________________________________
> > > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Thu, 14 Nov 2013 13:43:33 +0000
> > From: A.L.M.Buxey at lboro.ac.uk
> > To: mohamed nagy <eng.mohamednagy at gmail.com>
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] How to prevent https facebook from the cisco
> > router 1841
> > Message-ID: <20131114134333.GB9160 at lboro.ac.uk>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Hi,
> >
> > > i need to prevent users to open Facebook https traffic from my router
> > cisco
> > > 1841
> >
> > you will need to invest in other technology that can achieve this...and
> > wonder
> > why you dont get the best people working for your company. blocking
> > facebook isnt
> > a technical issue...its a human resource issue. if your company doesnt
> > want users
> > accessing facebook from your network (at which point they'll use the
> > 3G/4G/etc with
> > their own devices) then they need to know this and management need to
> deal
> > with it.
> > ensure proper disciplinary proceedings for anyone caught doing facebook
> on
> > company
> > time and then the problem will be solved.....(but see my point about the
> > sort of
> > people who will work there).
> >
> > alan
> >
> >
> > ------------------------------
> >
> > Message: 7
> > Date: Thu, 14 Nov 2013 08:05:37 -0600
> > From: Doug McIntyre <merlyn at geeks.org>
> > To: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] How to prevent https facebook from the cisco
> > router 1841
> > Message-ID: <20131114140537.GA45235 at geeks.org>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Thu, Nov 14, 2013 at 01:43:33PM +0000, A.L.M.Buxey at lboro.ac.uk wrote:
> > > > i need to prevent users to open Facebook https traffic from my router
> > cisco
> > > > 1841
> > >
> > > you will need to invest in other technology that can achieve this...
> >
> >
> > I agree about the technology part. Run a box built to do this sort of
> > thing. I wouldn't think of using any low-end router to do firewall
> > functions any longer, dedicated hardware firewalls are a fraction of
> > the price of router hardware, and can handle infinately more bandwidth
> > and features. I could block facebook (or just about any "internet app")
> > for an internal user in about 15 seconds of setup on my FortiNet
> > firewall that my users are behind.
> >
> > > .. blocking facebook isnt a technical issue...its a human resource
> > > issue. if your company doesnt want users accessing facebook from
> > > your network (at which point they'll use the 3G/4G/etc with their
> > > own devices) ..
> >
> >
> > If they have a 1841 router, it is probably a smaller company, and they
> > probably don't have the resources to police their users like a larger
> > company. A technology solution is easier.
> >
> > But it is a whole different thing to check sites on your phone
> > bypassing work restrictions, vs. on the desktop. On the desktop, it
> > is hard for a manager to see if the user is doing legit work functions
> > or not, but always fondling their phone is totally different looking
> > to the manager.
> >
> > If you need to just train the employee not to do the improper steps,
> > and putting in technology blocks is easier than standing over them
> > school teacher style to make sure they are working the full work day.
> >
> >
> > ------------------------------
> >
> > Message: 8
> > Date: Thu, 14 Nov 2013 16:34:08 +0200
> > From: Catalin Petrescu <cpmarvin at gmail.com>
> > To: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
> > Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> > Subject: Re: [c-nsp] [IOS XR] export to default-vrf
> > Message-ID:
> > <CAP=_-
> > 9N2HmXNHqruj+tDHOx4TMWUbAAmAXRZL+wsijmmJpk5Lg at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Thx Oliver .
> >
> > router bgp xx
> > address-family ipv4 unicast << this was missing
> >
> > vrf TEST
> > address-family ipv4 unicast
> > redistribute connected metric 10
> > redistribute static metric 10
> >
> > as the leak route is know via bgp ( in default vrf) and not
> > connected/static ( as in vrf )
> >
> > Regards,
> > Catalin
> >
> >
> > On Thu, Nov 14, 2013 at 11:07 AM, Oliver Boehmer (oboehmer) <
> > oboehmer at cisco.com> wrote:
> >
> > >
> > > >Hi all,
> > > >
> > > >Did anyone get this to work on XR 4.3.2.
> > > >
> > > >vrf TEST
> > > > address-family ipv4 unicast
> > > > export to default-vrf route-policy default_policy_pass_all
> > > >
> > > >route-policy default_policy_pass_all
> > > > pass
> > > >end-policy
> > > >
> > > >[...]
> > > >RP/0/RSP1/CPU0:#sh route vrf TEST
> > > >....
> > > >B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
> > > >17:54:43
> > >
> > > is this an iBGP or an eBGP vrf route you are trying to export? Only
> > > external or locally originated routes are candidates to be exported
> from
> > a
> > > VRF (anywhere, wether in global or into a different VRF), you need to
> do
> > > this on the originating PE. This rule is there to avoid loops, similar
> to
> > > standard BGP advertisement rule of only sending iBGP paths to external
> or
> > > RR-client peers.
> > >
> > > oli
> > >
> > >
> >
> >
> > ------------------------------
> >
> > Message: 9
> > Date: Thu, 14 Nov 2013 16:02:38 +0100
> > From: "Oswald, Thomas" <th.oswald at telekom.de>
> > To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> > Subject: Re: [c-nsp] nexus-switche issues no arp-requests
> > Message-ID:
> >
> > <D9F50A0C85164A44B0202D32455750A2041FC0D547 at QEO40075.de.t-online.corp>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > fuck! The faulty behavior disappears. Just rebooting the nexus-switch.
> Two
> > days to view a lots of logg-messages, error discovery, tests... For what?
> > For nothing. And now I'm not absolutely sure that the fault will not
> raise
> > up again. That does not inspire me with confidence.
> >
> >
> >
> > ^^?-?^^
> >
> > -----Urspr?ngliche Nachricht-----
> > Von: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von
> > Oswald, Thomas
> > Gesendet: Dienstag, 12. November 2013 17:42
> > An: cisco-nsp at puck.nether.net
> > Betreff: [c-nsp] nexus-switche issues no arp-requests
> >
> > Hallo all,
> >
> > I see a very strange behavior on my two nexus switches.
> >
> > Both are Nexus 5548 with L3-daughter-cards. Both do l2 and l3-switching,
> > ACL-filtering and other things. Furthermore I have a set of servers
> > connected to both switches in a vPC-setup. All in all I do nothing
> special.
> >
> > After reloading the primary switch (vpc-primary, root-bridge for all
> vlans
> > and hsrp-active with preemption for all SVIs) the switche comes back
> online
> > and after getting up all links and reconverging everthing the network
> > breaks. After a lot of debugging and curses and connection tries and a
> few
> > additional gray hairs later I have got it to work by pinging all
> > ip-addresses from the switch that I have previously rebooted.
> >
> > Later I do some tests to find out what was going wrong. I found out that
> > if I clear the arp-cache I will get the same issue. Pinging from server A
> > in one subnet to server B in another subnet doesn't lead to success,
> > because the switch issues no arp-requests. To make it work just ping
> server
> > B from the switch and all works fine. The switch does arp, the arp-table
> is
> > updated and the pings from the server A will reach the server B.
> >
> > Any ideas?
> >
> > Regards
> > Thomas
> > ^^?-?^^
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > cisco-nsp mailing list
> > cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> >
> > ------------------------------
> >
> > End of cisco-nsp Digest, Vol 132, Issue 44
> > ******************************************
> >
>
>
>
> --
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
More information about the cisco-nsp
mailing list