Skip to main content
Contributor
August 10, 2011
Question

LAN access to VIP

  • August 10, 2011
  • 4 replies
  • 4789 views
Hi folks. I have two questions please. 1) We have a Virtual IP setup for a webserver which is on the internal LAN. We can access the server just fine from outside the LAN. However, we can' t access the server from inside the LAN when we use the server URL. Is this something FGT 100A is preventing? Is there a setting firewall setting that will allow it? 2) When external visitors view our webserver, we log the source ip. However the source ip is only showing up as the FG ip. So no matter who visits, we only see the 192.168.1.1 as the visitor' s ip. Again, is there a setting somewhere that will pass on the actual ip? Thank you much.

    4 replies

    rwpatterson
    New Member
    August 10, 2011
    Welcome to the forums. In answer to question #2, untick the NAT option on any incoming policies. This just changes the source IP to be that of the FGT port. Needed for traffic going out to the Internet, not for incoming.
    Contributor
    August 11, 2011
    Thank you Bob, unticking the NAT that worked to solve #2. Jan, thank you for your suggestion for #1. Modifying the hosts file would work but we have many devices which makes the solution impractical. We also have many guest users that come and go. We do not have internal DNS because we don' t really have internal servers, except for that one web server.
    rwpatterson
    New Member
    August 11, 2011
    Try this: Create a policy with interfaces Wan -> DMZ, Source IP range INTERNAL (or LAN) IP range, destination DMZ server, and NAT enabled. Put this above all but the VPN policies. That worked for me. Traffic count never grew, but the traffic flowed... Don' t ask me why. (FWF60A, v3.7.x) NOTE: The destination may be the VIP definition. That firewall has been decommissioned, and I don' t have immediate access to the backup files to check it out. That' s from the top of my head. Found it! The servers were in the same subnet as the PCs here though. Your mileage may vary.
          edit 18          set srcintf " wan2"  <- Internet interface          set dstintf " internal"  <- server interface              set srcaddr " <internal_subnet>"               set dstaddr " vIP.Group.1"  " vIP.Group.2"  " vIP.Group.3"  " vIP.Group.4"           set action accept          set schedule " always"               set service " ANY"           set comments " NEEDED for internal PC access to NAT-ted web site!"           set nat enable      next  
    Jan_Scholten
    New Member
    August 11, 2011
    For 1. you URL probably resolves to the external address - it is always a source of problem to access the outside IP from the inside. Try to manipulate your internal DNS to resolve the url to the internal IP of the webserver. Do a check first: Edit c:\windows\system32\drivers\etc\hosts and enter 192.168.123.456 www.webserverurl.com With 192.168.123.456 being the internal address and webserverurl.com the URL. Does it work now? (you need to allow trasffic from internal ->Server of course
    ede_pfau
    SuperUser
    SuperUser
    August 11, 2011
    There' s nothing special with accessing a WAN VIP from the LAN. You define the VIP as you did - I use ' 0.0.0.0' as public IP as it' s dynamic. Then you define the incoming policy src int: WAN src IP: all dst int: DMZ dst IP: VIP service: ANY (for testing), DNS later no NAT (but it' s doesn' t hurt, just not necessary) Tested that on my LAN with a VIP' ed server on the same LAN interface. Thought I' d need some weirdo ' internal->internal' policy but it just works. Make sure that the DMZ server knows where to send packets with non-local source addresses, i.e. knows his gateway.
    rwpatterson
    New Member
    August 11, 2011
    I have found that the bigger boxes work as expected (port_x->port_y). The double-digit boxes may need some help (WAN_x -> internal). 100a fits this mold.
    ede_pfau
    SuperUser
    SuperUser
    August 11, 2011
    I run this setup on a 60B with 4.2.8. Might be that 3.x had problems with this though.