# Creating new internal network



## mrw5641 (Aug 14, 2015)

Hi all, I am trying to configure a 10.10.10.0 network on my firewall.

I have created the interface and I am able to ping it from the firewall. 

I changed the IP of my Linux to 10.10.10.7/24 but I can't get access to it using that IP address.

Is there any NAT rules that I need to create?

Thank you!


----------



## MitchConner (May 8, 2015)

I'm guessing this is for your ASA based on previous posts 

If you need your new internal network to reach the internet, you'll need a NAT configured. The best way to do this is inside the network object you created:

object network inside_lan
subnet 10.10.10.0 255.255.255.0
nat (inside,outside) dynamic interface


----------



## mrw5641 (Aug 14, 2015)

thanks mitch. 

I want 192.168.1.1/24 and 172.16.1/24 to have ssh access to the 10.10.10.0/24 network.


----------



## MitchConner (May 8, 2015)

Are the 192 and 172 ranges also on your inside network?


----------



## mrw5641 (Aug 14, 2015)

192 is my guest network
172 is DMZ


----------



## MitchConner (May 8, 2015)

Depending on your configuration, ACLs will help you achieve what you need.


----------



## mrw5641 (Aug 14, 2015)

Mitch,

So a NAT rule has nothing to do with getting access to certain networks internally?

Can you give me an example of how 172 would get access to 10.10?

I think I am confused. I know NAT is a translation but there are also some rules in NAT that seem to allow access.

For example there is a NAT that says
dmz inside obj-10.100.0.0/24 any
inside dmz any obj-10.100.0./24


----------



## MitchConner (May 8, 2015)

I thought from your op that you wanted to allow your inside network access to the internet, in which case nat is needed. That's not to say you can't nat your inside network to some other address range even when traffic is internal, in some cases you would want to do that.

If you just want to allow access from your dmz & guest to your internal network you can either change the security levels on your interfaces or create ACLs:

For example:

access-list inside-acl extended permit tcp 172.16.1.0 255.255.255.0 10.10.10.0 255.255.255.0 eq 22

access-group inside-acl in interface inside


----------



## mrw5641 (Aug 14, 2015)

Hi Mitch

It seems like creating that rule I lost my internet connection.


access-list inside-acl extended permit tcp 172.16.1.0 255.255.255.0 10.10.10.0 255.255.255.0 eq 22


----------



## mrw5641 (Aug 14, 2015)

Mitch, any suggestions?

Thank you!


----------



## MitchConner (May 8, 2015)

Lost internet access from which subnet/interface mate?


----------



## mrw5641 (Aug 14, 2015)

From the 172 network.

After your commands I did I lost it.


----------



## MitchConner (May 8, 2015)

Try adding this to the ACL:

access-list inside-acl extended permit ip 172.16.1.0 255.255.255.0 any log

If you get any further problems, it would be worth seeing your current config.


----------



## mrw5641 (Aug 14, 2015)

THank you Mitch

I will give it a try.

Do I need to do those 2 original commands and than your final command?

I guess what I am asking is how would 172.16.1. get access to the new 10.10.10 network on a linux machine?


----------



## MitchConner (May 8, 2015)

If you don't need your nat then you only need the acl statements.


----------



## mrw5641 (Aug 14, 2015)

Mitch, can you have more than 3 VLANs? 172, 192 and 10.100


----------



## MitchConner (May 8, 2015)

It depends on the license. If you enter show license into the cli, you'll be able to see the maximum number of vlans available on the asa.


----------



## mrw5641 (Aug 14, 2015)

Mitch -- let me ask you a question.

Within my access rules

I have some DMZ rules to allow traffic to certain IP's (SSH, FTP)

I have 10 rules there. 8 are access and 2 are DENY.

The next set up rules is LPOUT rules where I have 10 rules with 2 denies.

Do I need those denies?

Is my newly created rule never making it to the end of the ACL because of the denies?

Here is the dropbox to my rules

https://www.dropbox.com/s/oi11gbckftj1f30/rules.docx?dl=0


----------



## MitchConner (May 8, 2015)

Hi mate,

There is an implicit deny on the asa as a global rule and you should (depending on versions) have one on your interface acls. If you don't specify a line number when adding acls, they get pushed underneath the deny meaning you never hit the rules.

With the implicit deny in mind, you should never have deny statements on your acls, only permit statements.


----------



## mrw5641 (Aug 14, 2015)

Right because if there is no ACCESS rule it will get denied any way correct?

When I do a packet trace from 172.16.1.1 t o 10.10.10.1

Type - ACCESS-LIST Action - DROP Show rule in Access Rules table.  Config Implicit Rule


----------



## MitchConner (May 8, 2015)

That's partially correct. An ASA (and most firewalls in general) are default deny devices so anything not permitted will be denied.

However interfaces with a higher security level can flow to lower security levels by default meaning your LAN traffic from your clients can egress the WAN interface without an ACL, and don't need an ACL to allow the return because the ASA maintains a stateful connection. 

Traffic initiated from a lower interface to a higher interface, from your DMZ for example, would require an ACL inbound on that layer 3 interface to allow traffic in.

Some points to note from your ACL:

I would strongly recommend not using ANY statements in the ACLs. You'll need a lot more entries for your traffic, but more specific entries the better. It's generally ok to have an ANY on your inside network, but not ingressing your WAN interface.

I'd also recommend creating port-object groups to help manage your config in a more granular fashion.


----------



## MitchConner (May 8, 2015)

I forgot to add:

deny ip any any = good
permit ip any any = should not appear in your config in a security context.


----------



## mrw5641 (Aug 14, 2015)

Basically what I had done was removed the DENY entries in my ACL and I left the last rule IMPLICIT DENY in there.

I am still learning about the firewalls.

So the 10.10.10.1/24 interface I created I can ping that from the firewall.

Do I need to create an access rule and a nat rule for this device?

I want to be able to assign 10.10.10.* to one of my linux machines


----------



## MitchConner (May 8, 2015)

I like to keep a global implicit deny as a good rule of thumb as any traffic that doesn't match the ACL will hit that anyway.

If your 10.10.10.0/24 network is your inside lan, you'll need a nat to allow it to get onto the internet, if you just want local access, you don't need to bother.

I'd advise against allowing ssh from your dmz to your lan, dmz's usually contain public facing servers and it would be a security risk, and doesn't make sense from an administration point of view either.

However, i'm not judging your network and you probably have reasons for allowing it so:

(If you have access to asdm, i'd do it in there, because making sense of cli acl entries can be a bit much depending on how many you have and whether you're using objects, and although the cli is awesome, if you can do it easy then why not.)

CLI:

you'll need to ensure this acl matches your current dmz acl name and ensure that the sequence number is correct, and i'm assuming your 172 range is behind the dmz interface

conf t
access-list acl-name extended permit tcp 172.16.1.0 255.25.255.0 10.10.10.0 255.255.255.0 eq 22 log
access-group acl-name in interface dmz
exi
wri


----------



## mrw5641 (Aug 14, 2015)

That didn't work. It just deleted all of my DMZ rules.

rrr. frustrated


----------



## MitchConner (May 8, 2015)

Did miss the sequence number? You can reset in the asdm if you done it in there.

This will replace your acl:

access-list dmz-in extended permit ip any host 128.228.1.15 log
access-list dmz-in extended permit ip any host 170.225.15.1 log
access-list dmz-in extended permit ip host 1.1.0.163 any log
access-list dmz-in extended permit ip host 1.1.0.237 any log
access-list dmz-in extended permit ip host 1.1.0.109 any log
access-list dmz-in extended permit tcp host 1.1.0.132 any eq ftp log
access-list dmz-in extended permit ip 172.16.1.64 255.255.255.192 host 1.1.0.53 log
access-list dmz-in extended permit tcp 172.16.1.0 255.255.255.0 10.10.10.0 255.255.255.0 eq 22 log

access-group dmz-in in interface dmz


----------



## mrw5641 (Aug 14, 2015)

Mitch, it seems I lost internet on 10.100.0.* guests. I had those rules there to give them access to the internet. Not sure what happened.


----------



## MitchConner (May 8, 2015)

There's no rules for the 10 addresses on your dmz interface (or the 192 network) according to the document with the rules on them. Run the packet-tracer and see where it's dropping.


----------



## mrw5641 (Aug 14, 2015)

Is that part of an access list? 

Can't seem to figure out ;-(


----------



## MitchConner (May 8, 2015)

For example, if you've lost internet access from the 10 network, which is on your inside interface, put this into the cli and then post the output please:

packet-tracer input inside tcp 10.10.0.5 1024 8.8.8.8 80


----------



## mrw5641 (Aug 14, 2015)

It is actually on my DMZ (10.100)

inside(config)# packet-tracer input dmz tcp 10.100.0.163 1024 8.8.8.8 80

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 LPOUT

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 10.100.0.0 255.255.255.0 DMZ

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group DMZ_access_in in interface DMZ
access-list DMZ_access_in extended permit ip object inside_VMTEST any log debugging
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 338301647, packet dispatched to next module


----------



## mrw5641 (Aug 14, 2015)

I got it mitch. Somehow I d eleted my NAT for DMZ to LPOUT


----------



## MitchConner (May 8, 2015)

I see what's happened. The doc showing the acl has 1.1.0163 as a source (which i didn't give much thought to), i think it should be reading as a 10 address.

access-list dmz-in extended permit ip any host 128.228.1.15 log
access-list dmz-in extended permit ip any host 170.225.15.1 log
access-list dmz-in extended permit ip host 10.100.0.163 any log
access-list dmz-in extended permit ip host 10.100.0.237 any log
access-list dmz-in extended permit ip host 10.100.0.109 any log
access-list dmz-in extended permit tcp host 10.100.0.132 any eq ftp log
access-list dmz-in extended permit ip 172.16.1.64 255.255.255.192 host 1.1.0.53 log
access-list dmz-in extended permit tcp 172.16.1.0 255.255.255.0 10.10.10.0 255.255.255.0 eq 22 log

access-group dmz-in in interface dmz

I've amended the acl for those 10 addresses.


----------



## MitchConner (May 8, 2015)

How did you manage that  ?


----------



## mrw5641 (Aug 14, 2015)

I have no idea!

Thanks for the help mitch!


----------



## MitchConner (May 8, 2015)

Anytime mate.

If you're struggling with acl's in the future just let me know, I have a document i made a little while a go for training engineers on ASA's (with asdm & cli pictures) that gives a bit better explanation of access-lists, traffic directions, management of your rule base, etc that explains things a little more clearly than a bunch of forum posts.

I'll happily send it over, hopefully it will come in useful.


----------



## mrw5641 (Aug 14, 2015)

Absolutely., can you please send over?

Thank you!


----------



## MitchConner (May 8, 2015)

Here you go mate.


----------

