Internal website Access over VPN

ok my dirty fix was to create a firewall rule that allowed the tmgs external IP address access to 192.168.101.5 on port 80

i will hold out for a proper fix though!

Thanks

i did actually half of option 3, when you say create access rules are you meaning like the one i said above, allowed traffic from tmg external to tmg internal?

or we talking access rules to allow traffic to the sites public ips?
also the publishing rule onyl applies to external ips

or are you meaning to not publish websites at all using tmg?

option 2 would cost money which the company doesn't have

option 1, my cisco routers are running a dynamic multipoint vpn with gre/ipsec and eigrp, which i sort of like, its clever and is faster (whether noticable or not) than a software vpn connection

or we talking access rules to allow traffic to the sites public ips?

No. Users on the LAN do not use the Public IP#s to get to the internal web sites,...they use the exact Internal IP# of the Web Server itself.  

Access Rules:

From: Internal,  External
To: Internal External
Protocol: whatever
Users: whatever

In case you don't notice this pretty much wipes out any protection the TMG gives you and leaves you completely dependent on the "outer" Firewall for all your protection.  The Remote LANs are effectively part of "External" because of your bad VPN Design and hence it requires bi-directional access rules between Internal and External.  Although you could create an Address Set and use it in the Rule instead of "External"

or are you meaning to not publish websites at all using tmg?

Internal LAN users do not use Publishing Rules
Internal LAN users do not use do not use the Public IP#s to reach the Sites
If you use Publishing Rules for people out in Internet Land to access the Sites that is a totally different process that is completely unrelatated to what you were asking

ok yeah,

from our previous discussions i have a rule that allows

from: internal local host
to: remote sites (internal ip ranges)
named: intersite access

thats where im at

if you look at my topology above, when the traffic hits the firewall at Site A is its client ip is the external interface  site Bs firewall

and at site B, the name website.com is getting turned into webserver.local
is it becuase site B has local DNS records for website.com?

The name doesn't get changed to anything.  Names never change.
Your supposed to use the same Public Name for the site that anyone would use,...but your DNS is supposed to resolve it to the Internal LAN IP#.   That is called Split-DNS.   It is a "given" that Split-DNS is required and is setup on pretty much anyone's LAN,...so it is assumed to be there and is correctly configured.

yeah it is, i was just getting confused by the errors

here i am requesting website.com |192.168.101.5 and the firewall says it destination is dc1-webserver.domain.local, but the request is website.com, is that right, the destination is resolved but the header stays in tact?

then at site a, were getting requests from 192.168.205.253 the tmgs external interface not the clients ip address requsting it
it should go through the intersite access rule as its between two allowed lans

but its going out the external int, is this becuase of the proxy service?


errors.png

If you are using the proper FQDN in the browser,...and it resolves tot he correct Private LAN IP#,...that is all that matters.

You're just going to have to figure out what you don't have correct on the Rules,..I'm not there,..I can't  All I can do it tell you how the structure is supposed to be designed and laid out.  It is up to you from there.  Clearly something isn't right on the Access Rules on the TMG where the Web Server is at.

well the network layout is exactly laid out as we discussed and you showed me how to do properly since our last conversation, ill have to do some futher digging to try see what exactly is happening

illl get back to you...

thanks :)

ok ive gone over my network and its all working exactly as it should and we set up months ago

i have my two intersite access rules, i did some monitoring on the intersite access rules and all traffic but http traffic meets the intersite rule and has the clients original IP in the log (see screen)

but as you can see in the above screens, http traffic has the firewalls external interface as the client ip, not the orginal ip

what is about http traffic?
am i missing something?
Intersite-access.png

You said before that you did "half of option 3",....that probably means you only did it "half right",...you can't just do any of those options "half-way".

If you system is set up like it was "months ago" then that means it is like the diagram you showed me originally, which means the network is setup wrong.

There really isn't any more I can do with this.  All the information you need is scattered around in the above posts.

HTTP is probably always going to do what it is doing,...unless you disable the Web Proxy Service and the Firewall Service on Internal Network.  You have a bad design, if you won't change the design then you will have to deal with whatever you have to deal with..

its fully setup as per option 3, with the intersite access rules, all traffic uses the intersite access rule apart from http/s even though all outbound traffic is specified in the rule http/s traffic just does not listen to it?

does http/s traffic travel differently to all other traffic, something to do with web proxy perhaps?

just coming back to this (hopefully your still subscribed)

i thought of some sort of work around if you could cast your eyes across and offer some advice?

the possible layout ive attached (adding a third nic to TMG) then on that 10.1.1/24 network, would i tell that tmg that that network is inside and label it an inside nic?

would this be a satisfactory solution do you think?
Current.jpg
possible.jpg

I've requested that this question be deleted for the following reason:

As suggested by mod, deleting and reopening question

I think the worst thing you could do is start a new thread.  You have to start over with the explaination,....get everyone past their "first-impression-misconceptions" and "wild-goose-chases",....and then you probably won't get any better responses than you have now.  On top of all that it would probably be the same people giving the answers and suggestions anyway.    Forefront MVPs are not plentiful,..up until this last year or so there was only two in the entire USA and I was one of those two.

[Your last suggestion]
I don't see that solving anything,...it just looks like a way to over complicate things and make things confusing for no real purpose.

You need to go back to the original question with the original drawing,...which is the correct way to do it in the first place.

The Option #3 from my first post is the most direct and logical way to approach it if the Device external to the TMG is performing NAT.  It is just a typical Back-to-Back DMZ with the VPN terminated on the outer firewalls.  There are millions of these setups just like this all over the world.  You don't have anything different or unusual.  You just have to figure out what you did wrong from the beginning and correct it.

but as you can see in the above screens, http traffic has the firewalls external interface as the client ip, not the orginal ip
what is about http traffic?
am i missing something?
Intersite-access.png  8 KB

My best guess at this point is that the VPN is incorrectly setup on the Outer Firewalls and it is NATing the VPN Traffic when the VPN Traffic should never be NAT'ed.  The VPN Traffic should never show comming from any of the IP# of the Firewall performong the VPN,...it should always show coming directly from the IP# of the Client in the opposite network that is making the request.

If it is only doing that with HTTP then the Outer Firewalls have some kind of HTTP Proxying Service built into them that must be disabled.  I have seen the same issue come up with SMTP on Cisco ASAs that would get in the way of  Intra-Exchange communication between Exchange  Servers in the same company but in different Sites,...so it would not be too unexpected to see that with HTTP.

See my previous post.....

Thanks for coming back to me

I do have the network fully setup as per option 3, i have http inspection enabled on the edge firewalls.

my main issue is that:-

site B TMG external ip 192.168.205.253s ip address is hitting Site As external ip address (192.168.201.253) yet neither of these firewalls nor the edge firewalls know of either of those routes. they shouldnt even exist to one another

Those internal ips wouldn't propagate on the internet so that traffic has to sending over the VPN tunnel again which seems more than odd since those networks arent routed across my tunnel.

my new suggested layout sort of simulates your ideal layout of option 2 but its one device instead of 2, do you not favour that solution?

thanks again

assistance has been provided again

but as you can see in the above screens, http traffic has the firewalls external interface as the client ip, not the orginal ip

I'm looking back at the original diagram (I think it is best to look back at the beginning),..the IP being rejected is the external interface of the TMG on the client side of the situation.

The Network Relationship between Internal and External needs to be set to "Routed" on both of the TMGs (doing only one will not cut it).

If it is already set to "Routed" let me know,...there may be other measures to take

I do have the network fully setup as per option 3, i have http inspection enabled on the edge firewalls.

That may be the root of the problem.  When you enable HTTP Inspection it becomes a type of "HTTP Proxy",...which causes the false Source IP.   Disable the HTTP Inspection on the outer firewalls and it just may start working correctly.

TMG external ip 192.168.205.253

Wait.   Ok,...same thing I just said above however you have to do what I just said but only it would be at the TMGs instead.  Bottom line here is that nothing,....nothing,...should be running an HTTP Proxy (or HTTP Inspection) when the traffic is supposed to run between the two LAN Sites.

Give me time to write this one up,...it is not a "quickie".

Create two New Networks,...one on each TMG.

On TMG-101.254
Create a Network:
Name: LAN-105
Type: internal     <----Important!
Range: 192.168.105.0 thru 192.168.105.255
Relationship: Internal to LAN-105  =  Routed
In the Network Properties disable the Firewall Client and the Web Proxy Tabs.  To get to the Properties double-click on the Network after the Wizard finishes creating it

On TMG-105.254
Create a Network:
Name: LAN-101
Type: internal     <----Important!
Range: 192.168.101.0 thru 192.168.101.255
Relationship: Internal to LAN-101  =  Routed
In the Network Properties disable the Firewall Client and the Web Proxy Tabs.  To get to the Properties double-click on the Network after the Wizard finishes creating it

Add both of these Networks into the Destination Fields of any of the appropriate Access Rules.

Let's see if that accomplished anything.

If that doesn't work then you may have to disable the HTTP Application Filter from the HTTP Protocol and forget it. That would be the best I can do with your design choices.  This is one of the reasons I refuse to run a Back-to-Back DMZ and if I have devices running a VPN that are separate from the TMG I always place them on the LAN behind the TMG.so the VPN traffic never goes through the TMG to begin with.

ill give those things a whirl!

Just to answer your question, yes they are set to routed on both ends

If i had the budget to get a separate router and put it behind the TMG and use the front end 800 as a modem only I would

My suggested solution of putting a 3rd nic in and having that act like a dedicated link between the two sites, do you not like it, if so why?

Thankyou for all your help and advice

This question has been open long enough, thanks for your help in the matter, i am redesigning the network to suit a better setup whereby i am not allowing internal ips through the external ips of TMG, i am moving the VPN devices behind the firewall as they should be. (like option 2 in your earlier posts). get this setup the right way!

Thanks for your help