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.




Network Security Firewalls
[Top] [All Lists]

RE: PIX dhcprelay via IPSec.

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 problem
might 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>