[c-nsp] How to prevent https facebook from the cisco router 1841
Pablo Lucena
plucena at coopergeneral.com
Thu Nov 14 11:07:01 EST 2013
Right, if you read my first response it says that it will *NOT *work for
HTTPS. It will work however for HTTP traffic. I've tested it and it does
work.
On Thu, Nov 14, 2013 at 10:59 AM, Hari bamsha Sapkota <
sapkota.hari006 at gmail.com> wrote:
> 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.ukwrote:
>> > > > 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