Websense restriction access page does not display

Answered Question
Jul 1st, 2010

Hi halijenn / experts

I have an ASA 5505 8.2.2 Sec Plus license , which is integrated with websense (10.1.1.29) .The websense server is placed in the inside of Firewall . /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} The wired network ID is 172.30.1.0/24. and wireless network ID is 172.31.48.0/24 (both behind DMZ) .However, the wireless controller is performing NAT to 172.30.1.7 .The issue is that the websense restriction access page doesnot gets displayed for Wireless User (Packet is always sourced from the NATTED IP 172.30.1.7 to the Websense )  for the site which is configured to be blocked in websense (Though the site gets blocked); however it shows correctly for the Wired users (i.e the correct block page displays) . For the wireless users , instead of displaying Block webpage ; /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} Firefox error reports the server is valid but not accessible.

Note : There is a NONAT Access-list between the DMZ and Inside


/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman","serif"; mso-fareast-font-family:"Times New Roman";} nat (inside) 0 access-list nonat

access-list nonat extended permit ip host 10.1.1.29 172.30.1.0 255.255.255.0
access-list nonat extended permit ip host 10.1.1.29 172.31.48.0 255.255.255.0

route dmz 172.31.48.0 255.255.255.0 172.30.1.7

Websense config

url-server (inside) vendor websense host 10.1.1.29 timeout 30 protocol TCP version 1 connections 5
url-cache dst 100
filter url http 172.30.1.0 255.255.255.0 0.0.0.0 0.0.0.0 allow proxy-block longurl-truncate cgi-truncate

Syslogs for the blocked site (12.153.160.240) is as follows from the Wireless IP Address 172.30.1.7

Jun 30 2010 06:33:46: %ASA-7-609001: Built local-host outside:12.153.160.240
Jun 30 2010 06:33:46: %ASA-6-305011: Built dynamic TCP translation from dmz :172.30.1.7/2576 to outside(WWW):208.X.X.X/38631
Jun 30 2010 06:33:46: %ASA-6-302013: Built outbound TCP connection 735023 for outside:12.153.160.240/80 (12.153.160.240/80) to dmz:172.30.1.7/2576 (208.X.X.X/38631)
Jun 30 2010 06:33:46: %ASA-5-304002: Access denied URL http://www.smith-wesson.com/ SRC 172.30.1.7 DEST 12.153.160.240 on interface dmz
Jun 30 2010 06:33:47: %ASA-4-507003: tcp flow from dmz :172.30.1.7/2576 to outside:12.153.160.240/80 terminated by inspection engine, reason - inspector reset unconditionally.
Jun 30 2010 06:33:47: %ASA-6-302014: Teardown TCP connection 735023 for outside:12.153.160.240/80 to dmz:172.30.1.7/2576 duration 0:00:00 bytes 543 TCP FINs

Jun 30 2010 06:33:47: %ASA-7-609002: Teardown local-host outside:12.153.160.240 duration 0:00:00

Please let me know if the Wireless controller performing NAT is the cuplrit over here for some reason or is that the ASA is not able to rewrite the packet to redirect client to access restriction page (Websense works on 15871) ? I am confused as to why the ASA would behave differently for 2 IP address belonging to the same subnet ? It will be also helpful if you can explain as to how does the ASA rewrites the page so that client gets rediected to the block web page and also is a separate rule required from the DMZ to Inside for destination port 15871 on the websense IP Address ?

I have this problem too.
0 votes
Correct Answer by Jennifer Halim about 4 years 12 months ago

No separate rule is required for the websense to communicate from DMZ towards inside because websense url filtering is transparent to the host.

TCP/15871 is used by websense to send the block message back to the host.

In regards to the wireless controller performing the NAT, I don't think it will be able to initiate the TCP session towards the websense server on TCP/15871 for the block message. From real host perspective, the TCP/15871 is initiated towards the websense server. On the other hand, with the PAT address, it will not be capable of initiating the TCP/15871 session towards the websense server because it's just a PAT address not the real host address. From websense server perspective, all it knows is the PAT address and it has no knowledge of the real ip address of the host since it's being PATed.

If the websense is performing URL filtering on HTTPS traffic, it should still block it because the URL itself will not be encrypted. Only the data of the HTTPS session will be encrypted. Websense will still know what the URL is for the HTTPS traffic.

Hope that helps.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
ankurs2008 Fri, 07/02/2010 - 02:16

hi halijenn

can you please look into this query and let me know your views

Jennifer Halim Fri, 07/02/2010 - 04:45

Base on the information provided so far, here is my understanding of the problem:

- From the syslog messages, we are seeing that the websense server is correctly blocking access to http://www.smith-wesson.com/ (syslog# 304002) and the ASA would send a message back to the client to indicate the response is not successful which is actually seen on the next syslog messages (syslog# 507003).

- Your concern is you are getting a proper block page from wired connection, however, not getting a proper block page via wireless connection which is doing a PAT to 172.30.1.7.

I am suspecting at this stage that the wireless controller is not passing the block message back to the wireless host.

To confirm the actual behaviour, I would run packet capture on DMZ interface. Run 2 tests as follows:

1) ACL for packet capture: access-list cap1 permit tcp host host

Then apply the packet capture on DMZ interface.

Run the test and grab the packet capture

2) Second test would be to perform test from the wireless host. ACL for packet capture: access-list cap2 permit tcp host host 172.30.1.7

Apply the packet capture on DMZ interface, run the test and grab the packet capture.

If you are seeing exactly the same packet capture sequence and data between the 2 tests, that confirms that it's an issue with the wireless controller (perhaps something with the NAT).

Is there a requirement for the wireless controller to perform NAT? Are you able to test it without NAT on the wireless controller?

ankurs2008 Fri, 07/02/2010 - 08:46

Thanks for the excellent explanation again !!

I will surely take the packet capture as requested ; however it will be helpful if you can explain as to how does the ASA rewrites the page (or packet) so that client gets redirected to the block web page and also is a separate rule required from the DMZ to Inside for destination port 15871 on the websense IP Address ? Please note that in the below working logs (wired users) i can see a seperate connection building for 15871 towards websense (but notice that there is no seperate 3 way handshake ! )

Jul 01 2010 11:36:59: %ASA-7-609001: Built local-host outside:12.153.160.240

Jul 01 2010 11:36:59: %ASA-6-305011: Built dynamic TCP translation from dmz:172.30.1.153/63578 to outside(WWW):208.X.X.X/13596

Jul 01 2010 11:36:59: %ASA-6-302013: Built outbound TCP connection 763237 for outside:12.153.160.240/80 (12.153.160.240/80) to dmz:172.30.1.153/63578 (208.X.X.X/13596)

Jul 01 2010 11:36:59: %ASA-5-304002: Access denied URL http://www.smith-wesson.com/ SRC 172.30.1.153 DEST 12.153.160.240 on interface dmz

Jul 01 2010 11:36:59: %ASA-4-507003: tcp flow from dmz:172.30.1.153/63578 to outside:12.153.160.240/80 terminated by inspection engine, reason - inspector reset unconditionally.

Jul 01 2010 11:36:59: %ASA-6-302013: Built inbound TCP connection 763238 for dmz:172.30.1.153/63579 (172.30.1.153/63579) to inside:10.1.1.29/15871 (10.8.16.69/15871)

Jul 01 2010 11:36:59: %ASA-6-302014: Teardown TCP connection 763237 for outside:12.153.160.240/80 to dmz:172.30.1.153/63578 duration 0:00:00 bytes 799 TCP FINs

Jul 01 2010 11:36:59: %ASA-7-609002: Teardown local-host outside:12.153.160.240 duration 0:00:00

Jul 01 2010 11:36:59: %ASA-6-302014: Teardown TCP connection 763238 for dmz:172.30.1.153/63579 to inside:10.1.1.29/15871 duration 0:00:00 bytes 3438 TCP FINs

In the current situation Wireless controller needs to perform NAT .i have not tested it without that as it would require some internal permissions to do the same however was just wondering how it treats the block packet as ?

I have one more question related to the block page is that for the HTTPS Traffic , is is that the websense block page doesnot appear to client because of the HTTPS being encrypted ?

Correct Answer
Jennifer Halim Mon, 07/05/2010 - 06:19

No separate rule is required for the websense to communicate from DMZ towards inside because websense url filtering is transparent to the host.

TCP/15871 is used by websense to send the block message back to the host.

In regards to the wireless controller performing the NAT, I don't think it will be able to initiate the TCP session towards the websense server on TCP/15871 for the block message. From real host perspective, the TCP/15871 is initiated towards the websense server. On the other hand, with the PAT address, it will not be capable of initiating the TCP/15871 session towards the websense server because it's just a PAT address not the real host address. From websense server perspective, all it knows is the PAT address and it has no knowledge of the real ip address of the host since it's being PATed.

If the websense is performing URL filtering on HTTPS traffic, it should still block it because the URL itself will not be encrypted. Only the data of the HTTPS session will be encrypted. Websense will still know what the URL is for the HTTPS traffic.

Hope that helps.

Actions

This Discussion