Cannot connect from DMZ (internet router) to LAN interfaces Cisco CRS1000v

[DB49501]

I have a internet router with 3 interfaces:

- 1 WAN

- 1 DMZ (192.168.2.1) - servers 192.168.2.10/11/12/15

- 1 LAN (192.168.1.1)

Furthermore I have a Cisco CRS1000v internal router with also 3 interfaces:

- 1 LAN (192.168.1.2) - outside

- 1 SQL (192.168.3.1) - inside - servers 192.168.3.10/11/12

- 1 WIN (192.168.4.1) - inside - servers 192.168.4.10

I have an internet connection from SQL and WIN to the Internet. 

I can ping server from SQL to WIN.

I can ping servers from WIN to SQL.

I can ping servers from SQL and WIN to DMZ

But I cannot ping servers from DMZ to WIN or SQL. Tracert stops at 192.168.2.1 (LAN outside interface Cisco)

What am I missing here?

Enclosed you will find my running-config.

Any help would be appreciated and many thanks in advance.

Kind regards,

DB

[Seb Rupik]

Hi there,

You need to configure static PAT on the CSR:

!
ip nat inside source static tcp 192.168.3.10 3306 192.168.1.2 33061 extendable
ip nat inside source static tcp 192.168.3.11 3306 192.168.1.2 33062 extendable
ip nat inside source static tcp 192.168.3.12 3306 192.168.1.2 33063 extendable
!
ip nat inside source static tcp 192.168.4.10 3389 192.168.1.2 33891 extendable
!

From the DMZ you should be able to connect to 192.168.2.1:[33061-33062] to access the SQL services, and 192.168.2.1:33891 to access RDP on 192.168.4.10 .

On the router you may also need to configure static routes to the CSR:

!
ip route 192.168.3.0 255.255.255.0 192.168.1.2
ip route 192.168.4.0 255.255.255.0 192.168.1.2
!

cheers,

Seb.

[paul driver]

Hello

---

@Seb Rupik wrote:

Hi there,

On the router you may also need to configure static routes to the CSR:

!
ip route 192.168.3.0 255.255.255.0 192.168.1.2
ip route 192.168.4.0 255.255.255.0 192.168.1.2
!

---

I would say this is not required because if you do the above then your advertising those internal networks to this router which goes against using NAT on the CSR router.

[DB49501]

Hi Seb,

I've made the changes you suggested but unfortuanately it doesn't work yet. 

Enclosed you'll see the changes I made and one printscreen from the internet router displaying the 192.168.1.2 can be reached by ping.

Do you have any more suggestions?

Kind regards,

DB

[paul driver]

Hello
I would say you need to be able to ping each host to the inside global addressing of the WIN/SQL subnet and to do that you could create a additional natted subnet for each internal network so any external network can reach, These new external subnets would then match to each internal host via its external equivalent.

Example:
WIN host 192.168.4.4 natted to 192.168.24.4
SQL host 192.168.3.6 natted to 192.168.23.6

Then from DMZ you should then be able to reach:
192.168.4.4 via 192.168.24.4
192.168.3.6 via 192.168.23.6

rtr hostname
conf t
no ip nat pool DMZ-L 192.168.2.10 192.168.2.16 netmask 255.255.255.0
no ip nat pool DMZtoLAN 192.168.2.10 192.168.2.15 netmask 255.255.255.0
no ip nat inside source route-map MAP-DMZToLAN pool DMZToLAN reversible
no ip nat inside source route-map track-primary-if interface GigabitEthernet1 overload
no ip nat inside source list NAT interface GigabitEthernet1 overload
no ip access-list standard NAT
no route-map track-primary-if permit 1

ip route 0.0.0.0 0.0.0.0 GigabitEthernet1 192.168.1.1
ip route 192.168.23.0 255.255.255.0 GigabitEthernet1
ip route 192.168.24.0 255.255.255.0 GigabitEthernet1

ip access-list standard SQL
permit 192.168.3.0 0.0.0.255

ip access-list standard WIN
permit 192.168.4.0 0.0.0.255

ip nat pool DMX-LAN 192.168.24.1 192.168.24.254 prefix-length 24 type match-host
ip nat pool DMX-L 192.168.23.1 192.168.23.254 prefix-length 24 type match-host

ip nat inside source list SQL pool DMX-L
ip nat inside source list WIN pool DMX-LAN

internet rtr
ip route 192.168.23.0 255.255.255.0 <lan interface of CSR> 192.168.1.2
ip route 192.168.24.0 255.255.255.0 <lan interface of CSR> 192.168.1.2

[Seb Rupik]

@paul driver I like your solution, but if you are going so far as to NAT the only two inside subnets in their entirety you may as well scrap NAT on the CSR completely.

[paul driver]

Hello

---

@Seb Rupik wrote:

@paul driver I like your solution, but if you are going so far as to NAT the only two inside subnets in their entirety you may as well scrap NAT on the CSR completely.

---

Seb you don't have to, I was trying to show how matching on the two internal subnets to their individual external subnet (if applicable) provides a granular way to administer NAT, The above example can be tweaked to accommodate either static/dynamic specific host -host translation either way those internal hosts need NAT if you want to hide them from the outside domain, but you are correct if nat isnt required then no need for any translation.

[DB49501]

Hi Paul,

I have loaded your config into my Cisco and I am able to connect to the SQL and WIN from the DMZ. That is what I wanted. Thanks for that.

But now I am not able to connect to the internet from the WIN and SQL and I am not able to connect to the DMZ. These two things did work before. 

Can you help me out here? Enclosed you will find a printscreen of the new config. Many thanks in advance.

Kind regards,

Dennis

[paul driver]

Hello

---

@DB49501 wrote:

Hi Paul,

I have loaded your config into my Cisco and I am able to connect to the SQL and WIN from the DMZ. That is what I wanted. Thanks for that.

But now I am not able to connect to the internet from the WIN and SQL and I am not able to connect to the DMZ. 

---

It wont be the configuration now of the CSR rtr, It will no doubt be due to the internet rtr ( what device is it?) ,That looks like it may also be performing nat upstream or at the very least the routing for the internet rtr lan subnets and as you have now created 2 "external" subnets on the CSR rtr that wasn't valid before then you will need to make sure these subnets are also included in any upstream NAT/routing or firewall running on that internet device.

However saying that when you state you cannot connect to the DMZ, from where are you trying to connect from as nothing should have changed on that subnet regard connection from the internet?

Can you post the configuration of the internet rtr?

[DB49501]

Hi Paul,

Thank you for your reply. Enclosed you'll find the config of the internet rtr. It is from a pfSense device.

For your information I can ping from a server in the WIN network to the 192.168.1.2 interface (LAN). 

Kind regards,

Dennis 

[paul driver]

Hello

I am not able to open that file correctly, Can you confirm if that rtr is using NAT?

[DB49501]

Hi Paul,

I've made some printscreens of the nat settings. 

Dennis

[paul driver]

Hello

---

@DB49501 wrote:

I have loaded your config into my Cisco and I am able to connect to the SQL and WIN from the DMZ. 

I am not able to connect to the DMZ. 

---

If you can reach the SQL and WIN from DMZ , you should be able to connect from SQL/WIN to DMZ unless you have a firewall ruling denying the new subnets?

Can you ping the 192.168.2.1 from SQL/WIN?

[DB49501]

Hi Paul,

I can ping the 192.168.1.2 from the SQL and WIN. But I don't have internet access from the SQL and WIN servers and I can't get to the DMZ from SQL and WIN.

In my first config (before I posted this issue) I was able to connect to the internet and DMZ from the SQL and WIN, but I wasn't able to connect from the DMZ to the SQL and WIN. Now it's the opposite. I can connect to the WIN and SQL via nat, but have no internet access from SQL and WIN and can't connect to the DMZ.

Summarize:

SQL -> LAN -> DMZ (not working)

SQL -> LAN -> Internet (not working)

WIN -> LAN -> DMZ (not working)

SQL -> LAN -> Internet (not working)

DMZ -> Internet (working)

DMZ -> LAN -> WIN (working)

DMZ -> LAN -> SQL (working)

It seems the 192.168.1.2 doesn't know what to do with it. And it seems only traffic from DMZ is accepted and outside traffic isn't (SQL/WIN -> LAN -> Internet/DMZ) Do you have any (more) suggestions?

Kind regards,

Dennis

[paul driver · Accepted solution]

Hello 

Can you verify first the routing please.

CSR -

ip route 0.0.0.0 0.0.0.0 GigabitEthernet1 192.168.1.1
ip route 192.168.23.0 255.255.255.0 GigabitEthernet1
ip route 192.168.24.0 255.255.255.0 GigabitEthernet1

internet rtr
ip route 192.168.23.0 255.255.255.0 <lan interface of CSR> 192.168.1.2 < this static needs to specify the next hop ip
ip route 192.168.24.0 255.255.255.0 <lan interface of CSR> 192.168.1.2 < this static needs to specify the next hop ip

Then as I stated previously check the firewall rules for the statics relating to those new subnets - PfSence static rules