Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 2 subscribers
  • Views 3710 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Terminal service from Internal network to DMZ

Dr_Jones
Internal network: 192.168.30.x
DMZ: 192.168.20.x

I have a packet filter that allows:
Internal_network , Any--->DMZ_network, any and also a reverse packet for response.

Do I need to do a NAT translation for this also or should the packet filter alone be sufficient? 

As it is with just the packet filter it isnt working...Ideas?

Regards,
Jones  


This thread was automatically locked due to age.
Parents
  • 0
    Can you ping the machines on the DMZ network from the Internal network?

    I can on my setup, and I use these two masquerading rules:

    DMZ_NAT DMZ_Network__ -> All / All MASQ__External None
    Local_NAT  Internal_Network__ -> All / All  MASQ__External None
      
  • 0 in reply to VelvetFog
    Ok I added your NAT rule...still no joy. I can ping the DMZ interface on ASL but cannot ping any of the DMZ servers. 
  • 0 in reply to Dr_Jones
    Perhaps it is a filtering issue.

    In my filters, I have:
    Internal__Network Any Any Allow
    DMZ__Network {DMZ-Services} Any Allow

    My {DMZ-Services} service group is a list of the specific services that I allow out from the DMZ network.

    {ping}, {traceroute}, DNS, FTP, HTTP, NTP, PPTP and several others are included in the service group. I only have the services that I really need in this group, since it is a DMZ network, and my WiFi access point is also located on it, so I have to keep it buttoned down for security.

    How are you filtering between the Internal network and the DMZ network?   
  • 0 in reply to VelvetFog
    very strange... a quick reboot of the DMZ servers and all is well...I dont know if it was an issue with my filtering or something on the server but thank you for your input....

    Regards,
    Jones 
  • 0 in reply to Dr_Jones
    When a server reboot mysteriously "fixes" non-communication issues, it is often because the machine had bad data in its ARP (Address Resolution Protocol) cache. The ARP cache holds the local IP address to MAC address lookup table. On a Windows server (or workstation), you can flush the ARP cache without rebooting by executing:

    ARP -d *

    in a DOS box. This deletes all the entries in the ARP table, forcing the machine to recreate it with correct entries, as required, via local broadcasts.
      
Reply
  • 0 in reply to Dr_Jones
    When a server reboot mysteriously "fixes" non-communication issues, it is often because the machine had bad data in its ARP (Address Resolution Protocol) cache. The ARP cache holds the local IP address to MAC address lookup table. On a Windows server (or workstation), you can flush the ARP cache without rebooting by executing:

    ARP -d *

    in a DOS box. This deletes all the entries in the ARP table, forcing the machine to recreate it with correct entries, as required, via local broadcasts.
      
Children
No Data