Here is my case. I currently have a Cisco ASA5545 running ASA 9.8(2) / ASDM 7.9(2)152. The firewall is up and running with several VPNs and internet access, etc. We just received a new 1GB internet circuit which we want to test for a while before cutting over. -------------------------- For reference; G0/0 - Outside G0/1 - Inside G0/6 - ATT_Inside_Test G0/7 - 1GB_ATT_TEST -------------------------- I used ports G0/6 for my "test" internal network (192.168.69.0/24) and configured G0/7 for my new 1GB circuit. Now there is a default route already set that forwards traffic out the original internet port (G0/0 named Outside). How can I set this up so that only users on the new test network of 192.168.69.0 network with go out the new (G0/7) 1GB interface for internet access while all other users continue to use the original G0/0 interface? I did try to set this up for some testing but it appears not matter what I do or try even the traffic on the 192.168.69.0 net still wants to go out the "Outside" interface (G0/0) and not the new 1GB Interface (G0/7). Is what I'm asking for even possible? Obviously this is a production firewall so I am very limited on drastic configuration change options. Here is one example. 6 Jul 31 2019 15:12:09 302015 192.168.69.69 65261 188.8.131.52 53 Built outbound UDP connection 175781294 for Outside:184.108.40.206/53 (220.127.116.11/53) to ATT_Inside_TEST:192.168.69.69/65261 (192.168.69.69/65261)
... View more
This is what we are currently running on the C3650. Sorry I would have replied earlier but my email was down.
cat3k_caa-base.SPA.03.03.04SE.pkg cat3k_caa-drivers.SPA.03.03.04SE.pkg cat3k_caa-infra.SPA.03.03.04SE.pkg cat3k_caa-iosd-universalk9.SPA.150-1.EZ4.pkg cat3k_caa-platform.SPA.03.03.04SE.pkg cat3k_caa-wcm.SPA.10.1.140.0.pkg
... View more
We have been upgrading our infrastructure and replacing some older 10/100 switches with 10/100/1000. The original switches are mainly C3560-48 switching. The new switches we are installing are C3650-48TS-S switches. There was a couple items we noticed which we were able to resolve via a TAC case which was the duplicate IP issue. This was resolved by adding the following command to ALL ports.
ip device tracking maximum 0
The issue we seem to be running into now is one area of enterprise uses Multicast so we put them in their own separate, routable VLAN. Well since we began replacing our switching we have run into some odd errors. This department now has some uplinks using the older 3560 v12.2 IOS switches and some using the newer 3650 v15 IOS. We are thinking there might be some changes particularly with Multicast from the older IOS to the newer IOS which might be causing this issue. The problem is, when we deployed the original switches we just ran with the default Multicast configuration. We didn’t specify any settings.
My question is this. Has anyone else run into this issue with Multicast not working correctly when some users are on 12.2 IOS and others on 15 IOS?
I tried looking for documentation listing the difference in default Multicast configurations between the two IOS versions but came up empty handed. Any assistance with this is greatly appreciated!
This is the Show Multicast output on one of our 3560 switches.
Multicast Routing: disabled Multicast Multipath: disabled Multicast Route limit: No limit Multicast Triggered RPF check: enabled Multicast Fallback group mode: Sparse
This is the show Multicast on our newer 3650 switches.
Multicast Routing: disabled Multicast Multipath: disabled Multicast Route limit: No limit Multicast Fallback group mode: Sparse Number of multicast boundaries configured with filter-autorp option: 0
... View more
I have an ISP that has given us a 32 IP Block (30 IPs addressable). I have a switch which the inside interface of the ISP router is connected to. From another port on this switch I have connected to the Outside interface of the ASA. All this works as expected with no issues.
We have been asked to setup a second connection using another IP address from this block that needs to be in the DMZ. The router that will be supplied will establish a tunnel. We need to supply them the public IP and gateway as well as the internal IP before they ship the router to us. So I created a DMZ port on this firewall and connected that to a new router that can establish a tunnel. I used a private network and have a /30 IP scheme between this new router and the DMZ interface of the firewall. This too works fine. I can ping the inside and outside interfaces of the firewall wall as well as external web addresses.
The goal is to allow remote support connect to this new router via their established VPN tunnel to manage our servers on our internal network. What I cannot get to work currently is a ping from our internal network to the 172.16.6.2 DMZ address. I can see the packets hitting the firewall and a connection setup and teardown in the logs. I am sure I am making this out to be more complicated than it needs to be but the last thing I want to do it mess up the config of an active firewall.
Built inbound ICMP connection for faddr 10.5.9.1/4 gaddr 172.16.6.2/0 laddr 172.16.6.2/0
Teardown ICMP connection for faddr 10.5.9.1/4 gaddr 172.16.6.2/0 laddr 172.16.6.2/0
What I am not getting, is any replies. I am thinking this is a NAT issue more than a routing issue. I do have a route in my core stating 172.16.6.0 /30 10.5.100.110 /16 which the inside ip address of our firewall is 10.5.100.110.
I have not setup any NAT statements for the DMZ yet as I am not sure if I need to setup a static NAT or a dynamic NAT. I just need traffic that is destined from the 10.5.x.x /16 to the 172.16.6.x /30 to be forwarded to this DMZ. I also need to make sure that any traffic from this DMZ network can access our internal network. Of course once this is working I plan to lock down the specific ports they require.
Since this is an active firewall with a separate VPN already established I cannot affect any traffic that is already setup to use the existing outside interface of the firewall.
I have attached a sanitized screen shot of my logical layout for a clearer understanding of my question. Thank you very much in advance.
... View more
YAY!!! It works !!! I added the lines you suggested and now we are running again !!! Thank you soooooooo much !!!! global (Inside) 2 192.168.27.97 nat (Outside) 2 access-list PNAT outside static (Inside,Outside) 64.xxx.xxx.147 10.5.7.231 netmask 255.255.255.255 access-list PNAT remark Kaseya Remote access access-list PNAT extended permit object-group TCPUDP any host 64.xxx.xxx.147 object-group Kaseya_External_Management Route in our core pointing to .49 which is the NATTING firewall ip route 192.168.27.97 255.255.255.255 10.5.100.49
... View more
So I was on the right path....at one point then. I had grabbed 192.168.27.96 /240, thinking I would somehow NAT 192.168.27.97 to 64.xxx.xxx.147. Then add a route in my core to point traffic destined to 192.168.27.97 to the specific firewall. I must have been putting it in backwards then? I could not get it to work and then well. As you can see from the thread so far.. I'm a train wreak !! 192.168.27.97 is NOT used on my network at all so this should work right? So my final config should look something like this? access-list PNAT permit ip any host 64.x.x.x nat (outside) 2 access-list PNAT outside global (inside) 2 192.168.27.97 Of course the rest of the config would remain the same. I cannot begin to express my gratitude for your patience and assistance with this !!
... View more
That default route is probably the issue then. Try this - access-list PNAT permit ip any host 64.x.x.x Will this cause issues on the firewall with any preexisting VPNs or other systems using this firewall to access the internet (only a few if any). nat (outside) access-list PNAT outside <--- note the keyword outside at the end as well as in the interface part. global (inside) interface The NAT IDs, is this just an arbitrary number or does this need to be specific ID relating to an already existing ID? This is what I have currently.... global (Outside) 1 interface nat (Inside) 0 access-list Inside_nat0_outbound nat (Inside) 1 0.0.0.0 0.0.0.0 static (Inside,Outside) 64.xxx.xxx.147 10.5.7.231 netmask 255.255.255.255 access-group Outside_access_in in interface Outside what this this does is NAT all client internet IPs to the inside interface IP of the ASA as they pass from outside to inside. You can if you want use a different IP ie. not the interface IP. You need to make sure either way that the core has a route back to the IP used. If it is the interface IP it probably will but if you use a different IP from an unused subnet you need to add a route on the core for that IP pointing to the ASA inside interface. So if I’m understanding this correctly I would want to change the global (inside) interface to global (inside) 64.xxx.xxx.147 ? Note - 1) the acl permits all IP, you may want to restrict it to just the specific server ports 2) make sure you use a nat-id that is not in use 3) i have used this before successfully but i have also seen it break other NAT connections so you need to test out of hours. Sorry i can't be more specific but it was quite a while ago Yes, the breaking part is what I’m afraid of as well. I just want any outside user who is configured to hit 64.xxx.xxx.147 to be able to connect to the internal server 10.5.7.231 and then their traffic forwarded back to them.
... View more
Not sure why this didn't show properly in my last reply. Let's see if this works better. access-list Outside_access_in remark Kaseya Port 5721 Inbound Access access-list Outside_access_in extended permit object-group TCPUDP any host 64.xxx.xxx.147 object-group Kaseya_External_Management access-list Outside_access_in extended permit object-group DM_INLINE_SERVICE_3 any host 64.xxx.xxx.147 access-list Outside_access_in extended permit object-group DM_INLINE_SERVICE_1 any any
... View more
Jon Marshall The route would not be for the 64.x.x.x address though. The return traffic from the internal server would have destination IPs of the clients on the internet. That is what gets sticky here. This is just one of many T1 circuits we have in our enterprise. Our core has a default route out to our main internet circuit which is not this firewall in question. So you would need a default route from the core pointing to the inside interface to the ASA to account for all the possible internet IPs. That or if you don't want a default route to the firewall you would need to NAT all the source internet IPs as they pass through the firewall to the server. Yes, I’m thinking this would be my only possible option other than setting the servers default gateway to the inside interface of this firewall. Usually though a default route is used and you may have this already so routing might not be an issue. The configuration you have posted is referencing acls ie. one for NAT on the inside interface and one applied to the outside interface but you haven't actually posted the acls themselves. Sorry, I must have missed this while trying to filter the config. access-list Outside_access_in remark Kaseya Port 5721 Inbound Access access-list Outside_access_in extended permit object-group TCPUDP any host 64.xxx.xxx.147 object-group Kaseya_External_Management access-list Outside_access_in extended permit object-group DM_INLINE_SERVICE_3 any host 64.xxx.xxx.147 access-list Outside_access_in extended permit object-group DM_INLINE_SERVICE_1 any any You static NAT statement for the server looks fine other than it is doing NAT for all ports as opposed to just the specific port you mention. This is not necessarily an issue and wouldn't stop it working. Presumably your outside acl is only allowing traffic to that public IP on the specific port. I don’t know how to setup a NAT to a specific port using the ASDM, I thought that an ACL would need to be added after the NAT was created to limit the port(s). ---------------------------------------------------------------------------------------------------------------------------------------------------------- Marius Gunnerud As Jon has mentioned make sure that you have a default route in your core network pointing to the ASA inside interface. I cannot do this. Our default route points to our main internet circuit for the enterprise. The firewall in question is just a T1 with a few VPNs on it. Since the VPNs do use a lot of bandwidth we wanted to use this same firewall for our external Kaseya clients to communicate to the Kaseya server inside our network on port 5721 As for NATing port 5721 to the Kaseya server the command would look something like this (given that it is the outside interface IP that is being translated: static (inside,outside) tcp interface 5721 10.5.7.231 5721 Would help to see the ACL configuration if you still have problems. I have done so many things at this point trying to get this to work I have completely confused myself. The command you listed above. Is this to replace the current static (Inside,Outside) 18.104.22.168 10.5.7.231 netmask 255.255.255.255 I have or along side? The external block I have for this T1 circuit is .146 /240. Will this mean the firewall will see the traffic being sent to .147 without the need for the .147 NAT or will it just forward ALL traffic coming into the firewall on port 5721 to 10.5.7.231? And if you require help with the VPN tunnels, we would need to see the crypto configuration as well as all related ACLs and NAT0 Amazingly enough the VPNs are not an issue and are functioning correctly. Though while fighting with this I have had to reload the firewall a few times without saving the config as I had completely hosed it...
... View more