Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | RE: PIX dhcprelay via IPSec. |
|---|---|
| Date: | Thu, 16 Mar 2006 17:28:54 -0000 |
sonds like that might be a routing issue. Is there a route on the inside interface for the address you're trying to ping? -----Original Message----- From: Meidinger Chris [mailto:chris.meidinger@badenIT.de] Sent: 16 March 2006 07:44 To: Stejerean, Cosmin; firewalls@securityfocus.com Subject: RE: PIX dhcprelay via IPSec. Hi Cosmin, I forgot to mention in my original post, that I can hping on udp/67 in both directions as well. I've also noticed, that on the remote firewall i can't ping the DHCP-Server normally, but i can if I specify the inside interface. That is, "ping x.x.x.x" doesn't work, but but "ping inside x.x.x.x" does work. Can anyone think of a reason for that? I'd appreciate any more ideas, because I've got quite a bit of pressure to get this running. Thanks, Chris
-----Original Message----- From: Stejerean, Cosmin [mailto:cosmin@cti.depaul.edu] Sent: Thursday, March 16, 2006 3:04 AM To: Meidinger Chris; firewalls@securityfocus.com Subject: RE: PIX dhcprelay via IPSec. Do you have rules to allow traffic on UDP 67 on all the PIX boxes? The
fact that you can ping the DHCP server means you can deliver ICMP packets but UDP packets on port 67 might be filtered along the way. Try to send a UDP packet on port 67 to the DHCP server using nmap and see if your sniffers pick it up. If it gets dropped you should see where it gets dropped. If this udp packet makes it through then you probably have some more serious issue with the remote pix. Also make sure the return packet can make it's way back to the remote pix. Regards, Cosmin Stejerean-----Original Message----- From: Meidinger Chris [mailto:chris.meidinger@badenIT.de] Sent: Wednesday, March 15, 2006 5:22 PM To: firewalls@securityfocus.com Subject: PIX dhcprelay via IPSec. Hi List, I have a question about relaying DHCP over VPN with PIX. I have the following setup: Client | | | Remote Site PIX running in network-extension mode |V| |P| Internet |N| Central PIX acting as concentrator | | Net 1 | Inside Pix providing access control | | Net 2 | DHCP Server x.x.x.x The client needs to talk to the DHCP-Server in Net 2. It can ping the DHCP fine so routing and all is OK, but the relayed Unicasts on udp/67 seem to die inside the remote PIX. No log messages, no debug messages (at least in any debug mode I though to try) and still no packet. I have the following config: hostname(config)# show dhcprelay dhcprelay server x.x.x.x outside dhcprelay enable inside I see statistics, hostname(config)# show dhcprelay stat Packets Relayed BOOTREQUEST 0 DHCPDISCOVER 48 DHCPREQUEST 0 DHCPDECLINE 0 DHCPRELEASE 0 DHCPINFORM 0 BOOTREPLY 0 DHCPOFFER 0 DHCPACK 0 DHCPNAK 0 but no packet in Net 1 and no packet in Net 2 (got inline sniffers in both trying to troubleshoot this) Can anyone point me in the right direction what the problemmight be?Thanks in advance, Chris
======================================================================================================================== The information contained in this e-mail is intended only for the individual to whom it is addressed. It may contain privileged and confidential information. If you have received this message in error or there are any problems, please notify the sender immediately and delete the message from your computer. The unauthorised use, disclosure, copying or alteration of this message is forbidden. Neither Vertex Data Science Limited nor any of its subsidiaries will be liable for direct, special, indirect or consequential damage as a result of any virus being passed on, or arising from alteration of the contents of this message by a third party. The following Vertex companies are authorised and regulated by the Financial Services Authority: - Exchange FS Ltd trading as The Exchange - Marlborough Stirling Mortgage Services Ltd trading as Marlborough Stirling Mortgage Services - Vertex Administration Ltd Vertex Administration (IOM) Limited is supervised by the Isle of Man Insurance and Pensions Authority. Vertex Data Science Limited (England and Wales No. 3153391) registered office Vertex House, Greencourts Business Park, 333 Styal Road, Manchester, M22 5TX ========================================================================================================================
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: PIX dhcprelay via IPSec., Udechime, Elias [NTK] |
|---|---|
| Next by Date: | AW: Re: PIX dhcprelay via IPSec., Meidinger Chris |
| Previous by Thread: | RE: PIX dhcprelay via IPSec., Udechime, Elias [NTK] |
| Next by Thread: | RE: PIX dhcprelay via IPSec., Meidinger Chris |
| Indexes: | [Date] [Thread] [Top] [All Lists] |