About gfullage

gfullage · ‎07-21-2017

Boy, had to scan the archives to find this. I don't even know how valid this is any more really, as the IOS config has moved on quite significantly from there, but I've attached the HTML file I made up years ago and a small picture to go along with it. Note the .txt file will need to be renamed to .html, then you sould just be able to browse to it directly. This system wouldn't let me upload a .html file. Have fun.

gfullage · ‎06-22-2010

The 302014 syslog messages are fairly standard when a TCP connection through the firewall is torn down. Remember that the ASA is a stateful firewall so it keeps track of the state of every TCP connection that comes through it. If at some point something tears that connection down then the ASA will not allow any more packets through on that connection. All the syslog messages and their meanings are documented here: http://www.cisco.com/en/US/docs/security/asa/asa80/system/message/logmsgs.html#wp4770614 As you can see, the "TCP Reset-O" meaning on the first message means that the firewall saw a RST packet come from the outside host. At this point the firewall will remove the connection from its connection table and no further packets will pass. Why the outside host sent a RST is something only the outside host can answer. The "failover primary closed" is, assuming these came in around the same time (which they did going by the TCP port numbers), is actually from the standby firewall unit saying it has closed down the same connection due to the active unit closing it down. You must have stateful failover enabled, so that all active connections on the active firewall are replicated over to the standby firewall. Conversely all connections that get torn down on the active unit (the first syslog), then get torn down on the standby unit (the second syslog). Hope that helps.

gfullage · ‎01-11-2010

Only thing I can think of is that the 192.168.3.x web server doesn't have a default route pointing back towards the inside interface of the PIX. It must have a route for the 192.168.1.x network cause you can ping it from the PIX itself, but traffic coming from the Internet is going to have a public IP source address, and so the web server will need a default route that get's that traffic back to the PIX. Check that. Thanks, Glenn.

gfullage · ‎01-11-2010

You won't be able to create another static mapping the 192.168.1.9 internal address to the same external IP address as the .8 server. If you have a spare public IP address allocated from your ISP then you can just create a second static for the outgoing mail, although that will obviously cost you additional money. However, you may not really need a specific public IP address for outgoing mail. Certainly you need a public one for your incoming mail so that the mail can be properly directed to your incoming mail server, but outgoing mail could be treated just like any other outgoing traffic, couldn't it? What I mean by that is, why do you need a specific public IP for your outgoing mail, why not just let it use the standard nat/global that all your other outgoing traffic is using? That way you wouldn't need a second static nor need a second public IP address. Not sure if that helps you or not. As I said at the start though, if your outgoing mail must come from a specific IP address then your only option is to get a second public IP address and add a second static. You canNOT create two statics mapping the same external address to two different internal addresses. Thanks, Glenn.

gfullage · ‎04-07-2009

The FWSM (or the PIX/ASA) does NOT allow FTP proxy connections. These are seen as a security risk and therefore denied. If you look at the syslog messages, you'll see a message similar to: *****%FWSM-4-406002: FTP port command different address: 1.1.1.1(172.25.8.81) to 172.30.201.24 on interface inside******

gfullage · ‎02-26-2008

There is a large amount of detail regarding this "vulnerability" at our PSIRT pages: http://www.cisco.com/warp/public/707/cisco-sr-20060726-ike.shtml

gfullage · ‎02-10-2008

Your configuration is OK, I have the exact same in mine and OS learning is working fine. Are you sure your SSM is seeing traffic from the ASA, have you set up a service policy to direct traffic to it? Do "sho service-policy" on the ASA and make sure it is actually sending data to the SSM.

gfullage · ‎02-10-2008

This is bug CSCsm15806, where if you have any interface on the ASA configured with a 255.255.255.252 mask, ASDM throws an error when you try and add a snmp-server with a host address that would be a broadcast address with that mask. The interface doesn't matter, it's just if you have any interface with a 255.255.255.252 mask on it. The bug was only fixed 4 days ago so is not yet in an official release. For the time being, just add the snmp-server via the CLI and you'll be OK, but upgrade to 6.0(4) when you see it on the web site.

gfullage · ‎02-10-2008

"Inside" is the host on the higher security interface. It doesn't necessarily have to be on an interface called "inside" though. For example, if it's traffic from DMZ (sec-level 50) to outside (sec-level 0) then in this case the DMZ interface would be considered "inside".

gfullage · ‎01-13-2008

Syslog message 106023 simply indicates that the firewall has denied a packet based on the src/dest in the syslog itself. What I would be asking is why are so many different external servers trying to send email (TCP/25) to my web server? Is your web server an email server as well? Is your web server listed with an MX entry in DNS for your domain? If so, why are you not allowing other mail servers to send email to it?

gfullage · ‎01-13-2008

Yep, you can do this with two static statements as below: Original Packet: Src:1.2.3.4 dst:4.5.6.7 Translated Packet: Src:10.2.3.4 dst:10.5.6.7 static (inside,outside) 10.2.3.4 1.2.3.4 static (outside,inside) 4.5.6.7 10.5.6.7

gfullage · ‎01-10-2008

Your IP address pool is part of your internal DMZ subnet. When packets come into the ASA from the DMZ hosts destined to the VPN clients, the ASA is going to look in it's routing table to see where it should send them. The ASA is going to believe that these addresses reside on the DMZ subnet cause that's where they fit, and so is going to send the packets back out that interface, NOT out the external interface as you think it might. Change your VPN pool to be addresses in the external subnet, or make them a completely different subnet (like 10.1.1.1-10.1.1.5), and then add a static route to the ASA pointing 10.1.1.x out the EXTERNAL int (and make sure your DMZ hosts route 10.1.1.x to the ASA via their default gateway setting).

gfullage · ‎01-10-2008

This is expected behaviour. The ASA will only use a DHCP server for assigning an IP address to the client, and will therefore ignore all other information sent from the DHCP server. If you want to assign DNS/WINS/etc parameters to the VPN client then you do this via commands under the specific group-policy: group-policy examplepolicy internal group-policy examplepolicy attributes dns-server 1.1.1.1 3.3.3.3 wins-server 2.2.2.2 4.4.4.4 default-domain value cisco.com See http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/vpngrp.html#wp1166190 for all the parameters you can define.

gfullage · ‎01-09-2008

It works differently depending on whether you're in IDS or IPS mode. IDS Mode When the trigger packet is seen and the alert fires, 100 TCP RST's are sent from the sensors MONITORING port to both the client and server. These 100 RST's have incrementing SEQ/ACK numbers to give us a better chance of actually getting within the current window and effectively resetting the connection on both ends. (It's important to realise that it is not 100% guaranteed to actually RST the connection due to this sliding window). The RST's are obviously sent out with the actual client and server addresses in them to make it look like it came from the other end. Because they're sent out the monitor port, if this is set up using a "span" session on the switch then it's important to make sure you allow inbound packets on that port (by default span ports drop inbound packets). IPS Mode Because the sensor is now inline, as soon as the signature fires we send one RST to both ends of the connection and then stop transmitting any further packets on that connection.

gfullage · ‎01-09-2008

The trouble with LDAP is the password is stored in the clear and therefore has to be sent in the clear. Note from the previous table that the only authentication methods that LDAP support all send the password in the clear (albeit some of them within an encrypted tunnel). EAP-GTC is generally used for token (one-time) passwords, which are OK to send in the clear since they're only valid one-time. GTC stands for Generic Token Card. I'm not actually sure if you cna just use it for non-token authentication, never even thought about it. PEAP(EAP-TLS) might be better, but will require certs, or EAP-FASTv1a (Phase two in the table) which comes with ACS v4.0 by default.

Date Registered	‎06-24-2002 07:42 PM
Date Last Visited	‎09-19-2018 01:50 AM
Total Messages Posted	3,628
Total Helpful Votes Received	1732

Boy, had to scan the archives

Re: asa5520 error messages

Re: PIX 515 NAT for Inside Remote Netw...

Re: Help with Public-to-Local IP Mappin...

Re: FWSM with Proxy FTP error, help!!!!...

Re: IKEv1 vulnerability on ASA 5520, ca...

Re: AIP-SSM POSPF not working at all

Re: Error adding snmp-server host

Re: RESET-I Meaning

Re: Deny TCP Reverse Path Check

Re: Nat SRC and DST on an ASA

Re: VPN Remote Access Issue

Re: ASA VPN DHCP parameters

Re: TCP RESET

Re: ACS,Novell and EAP-FAST