| Home | Register | Members | Search | Windows Vista Tips | File Database | Links |
 |
| Thread Tools | Display Modes |
|
Guest
Posts: n/a
|
|
|
|
||
|
|
| |
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
Finally got the change ip wizard to change the IP's, so they are finally
set up properly. Or well... somewhat properly. Now we run into the strange issue that the security server registers it's external, not it's internal, IP in the DNS. Which makes me think the interfaces were swapped at some point. This might also explain why the SMTP rule points to the internal IP. It might just consider it the external interface on some weird point. Now I can't run the change ip wizard anymore. It claims I'm either not administrator, or that it has no connectivity to the domain. I can access fileshares etc. just fine though. Can also connect with computer management to other servers etc. On 30-12-09 12:00, Freaky wrote: > Trying to track this at a lower level. > > Apparently during the original installation my collegues setup internal > as 10.1.1.254/24 and external as 10.10.1.254/16. The subnets are > actually reversed on this and they changed these manually (ie without > the wizards). > > I'm guessing the rule generation wizard (or whatever it's called  )> pretty much borks out on this change. > > Trying to re-set the IP addresses with the change ip address tool, but > this isn't working as the wizard has some dumb requirement on me > entering a gateway on the internal interface for the security server. > The security server obviously only has a gateway on the external > interface and the wizard refuses to reconfigure without entering the > gateway. > > So far no solution on that. > > They also changed the password for the administrator, but it seems this > only has causes issues with monitoring, which should be resolved now. > > Think the best way to proceed now is to somehow get the wizard to change > the ip addresses to the proper ones, reset the firewall rules back to > default (i hope by default it means recreating them, not importing a > backup from installation time...) and fixes edge stuff etc. > > Found some docs in which the edge server uses the external DNS servers > for routing to the outside world, but this currently isn't possible > either as with the default firewall rules the security server itself is > not allowed to connect to DNS servers on the internet. Only DC's are > allowed, atleast with the security level set to medium-high. Whether or > not this is because rules aren't generated properly or if it's a mistake > in the rules creation is yet to be seen. > > The IP isn't really reachable from the outside, you need to publish > firewall rules for it. That it is wrong is quite obvious however, it > should just publish the external IP. The funny thing is that it allows > from anywhere, from interface external to the IP on the internal side... > I would have just chosen the IP on the external side as 25/tcp is bound > to all according to netstat anyways (0.0.0.0:25 is listening). This is > the default rule created by the management server (I have 'reset' the > rules to default however through the EBS console and as mentioned I'm > not sure whether it recreates them based on info it has on IP > settings/network layout or if it just imports the rule set it created on > installation). > > Unfortunately this is our only EBS installation so I can't check how it > creates the SMTP publish rule on a normal operating EBS setup. If you > could check on your side that would be awesome .> > The rule settings: > > Name: Allow incoming email by publishing SMTP Mail Server > Enabled / Allow / Log requests matching this rule > Protocol: SMTP Server > From: Anywhere > To: 10.1.1.254 (internal IP Security/Edge Server) > Requests appear to come from original client (luckily it got this right > otherwise we'd probably be open relay  )> Networks: External > Schedule: Always > > Thanks for the re' > > On 30-12-09 10:38, Cliff Galiher wrote: >> Even with NAT disabled, my point is that a NIC gets an IP bound to it as >> part of the windows networking stack initialization. Even with a rule >> published in TMG, that IP should not be directly accessible externally. >> You may not agree with me on that point, but considering you obviously >> *have* problems with traffic getting to and from your security server, >> you may not want to dismiss my assessment *quite* so quickly. That is, >> of course, ultimately your decision to make however. >> >> -Cliff >> >> >> "Freaky" <> wrote in message >> news:... >>> No, not really. I have turned of NAT and set it to routing. The >>> Fortigate knows the route oc and there is a publish rule in TMG that >>> exposes it. Without the TMG publish rule internal is not reachable. >>> >>> All e-mail is stuck in the queue under 'submission'. Normally, when >>> routing to external, it creates queues for the domainname. >>> >>> Thanks for the re'. >>> >>> >>> >>> On 29-12-09 19:47, Cliff Galiher wrote: >>>> Just the fact that you can forward traffic to 10.1.1.254 is a sign that >>>> you have a physical network problem. The NIC with that IP should not be >>>> directly reachable from the fortigate, so the fact that the fortigate is >>>> reaching it shows an exposed internal NIC on the external network. >>>> >>>> -Cliff >>>> >>>> >>>> "Freaky" <> wrote in message >>>> news:#L#... >>>>> Hi there, >>>>> >>>>> whilst I was on vacation my collegues installed our first 2008 EBS >>>>> server(s) at our office location. Whilst doing this they used the DNS >>>>> servers for our ISP, as well as probably some other settings they >>>>> had to >>>>> change to make it fit the network here. >>>>> >>>>> Currently the network layout is as follows: >>>>> >>>>> >>>>> Internet <ext ip> FortiGate Firewall <10.10.1.1> <-> <10.10.1.254> TMG >>>>> Server <10.1.1.254> <-> LAN (10.1.x.x/16). >>>>> >>>>> By now I finally got the outgoing e-mail working. Several things I find >>>>> *extremely* peculiar. >>>>> >>>>> I have reset all the firewalls rules back to default on the TMG server, >>>>> enabling everything as it was. As there is an internal subnet between >>>>> the external gateway and the TMG I have changed TMG to do routing (and >>>>> thus not NAT) on the external IP. Changed the security level to >>>>> medium-high and added a rule to allow all traffic out (otherwise only >>>>> HTTP/HTTPS gets out from clients). >>>>> >>>>> First thing I noticed is that in the default rules SMTP is published, >>>>> but this is not reachable on the external IP of the TMG (10.10.1.254). >>>>> Telnetting to 10.10.1.254 25 from the fortigate (from 10.10.1.1 thus) >>>>> results in no connection. Forwarding 25 from the external IP on the >>>>> fortigate to the 10.10.1.254 IP (external TMG) results again in no >>>>> connection. This I find very peculiar, as if there was no additional >>>>> firewall the 10.10.1.254 should be considered external and thus SMTP >>>>> traffic should work on it, otherwise one can not receive email at all. >>>>> >>>>> Forwarding to 10.1.1.254 works though. Which I find very peculiar (I >>>>> did >>>>> add a route on the fortigate that 10.1.0.0/16 is behind 10.10.1.254 oc) >>>>> and scary as it's forwarding to an internal IP behind another firewall >>>>> and that firewall should be routing/accepting or nat'ing/forwarding it, >>>>> and I think something is seriously borked because of this. >>>>> >>>>> Mail now enters the queue on the TMG/Edge Transport. There the first >>>>> thing I see in message tracking is it entering from external client IP >>>>> to 10.1.1.254. And after that things start to get really strange. >>>>> >>>>> I see the same e-mail message tens of times after that, only now it >>>>> comes from the internal IP of the fortigate (10.10.1.1) going to >>>>> 10.1.1.254 (internal TMG) (I think it is source NAT'ed because the >>>>> source was internal and then going to external IP (because of DNS >>>>> lookup >>>>> resulting in MX records pointing at external IP) and because then after >>>>> port forward it would look like 10.1.1.254 -> 10.1.1.254 it is source >>>>> nat'ed by the fortigate to keep it working). After that it will show up >>>>> as going from 10.10.1.254 (external TMG) going to x.y.200.1 (where our >>>>> external IP is x.y.200.125/29, so not in our subnet but definitely >>>>> close). I don't know what the modem uses as gateway, our gateway is >>>>> x.y.200.126 (which is the modem thus) and I am guessing it's the >>>>> gateway >>>>> behind the modem. >>>>> >>>>> These 2 lines repeat over and over. There is no mailserver on the >>>>> x.y.200.1, there is no smarthost configured either (all mail should be >>>>> routed through DNS), so why it hits that IP is beyond me. I don't find >>>>> the tracking center very informative. In 2003 one could see states, >>>>> etc, >>>>> all you see now are some ID's, IP's and that's about it. Can I see >>>>> more? >>>>> >>>>> It seems that although the edge server recognizes the domains for >>>>> incoming as accepted locally, it doesn't know how to route them to the >>>>> exchange server. What's also strange is that recipient filtering is on, >>>>> it still accepts which it then >>>>> obviously would need to bounce afterwards. >>>>> >>>>> Earlier I didn't get any mail out either. It all got stuck in the >>>>> outgoing queue with a 451 DNS lookup failure. Removed the DNS servers >>>>> (externally) that were entered in the external interface. Besides the >>>>> fact they aren't from the ISP the customer uses (and thus won't >>>>> respond) >>>>> the default TMG settings actually do *not* allow the TMG server to >>>>> access DNS on the internet. So I'm just using the internal DC's DNS >>>>> servers now which is fine. Still didn't work as the Edge Transport was >>>>> still trying to use DNS servers from the external interface, which were >>>>> none.... So set them manually in the edge transport config. Outgoing >>>>> mail is fine now. >>>>> >>>>> On 2003 SBS one would probably easily solve this by running the >>>>> internet >>>>> and e-mail wizard again, but I see nothing of the likes. >>>>> >>>>> I'm somewhat reluctant to continue troubleshooting with my default >>>>> methods as these are non-EBS/SBS oriented. With 2003 this frequently >>>>> resulted in the very fine wizards biting us in the ass when they were >>>>> ran again and so I'd like to do this as much through the official EBS >>>>> wizards/toolies as possible. >>>>> >>>>> Any help is greatly appreciated. >>>>> >>>>> TIA >>>> >>> > |
|
|
|
|
|||
|
Guest
Posts: n/a
|
Ok some things are becoming more clear now. Finally sorted out the lower
level issues with the wizards not being aware of the correct IP/subnets and some other issues due to changes without the official wizards. If I reset the firewall rules to default now, SMTP is still published to the internal interface of the security server. However, it is then accessible through the external IP (whilst NAT is still turned on as is default on medium-high security). If I turn off NAT, it stops working however (on the external IP thus, as the external firewall knows how to route to internal that works... apparently this does use the publishing rule for acceptance of the traffic but not for the NAT part. Removing the publishing rule removes access to SMTP on the internal IP as well). My guess would be because the NAT setting is turned off and publishing requires some form of NAT (dst nat). If I forward to the Exchange server (yes I know I'm not supposed to do this, it's just for testing) a publishing rule works fine. Which leads me to conclude that DNAT on it's own interfaces won't work with NAT turned off. Which actually makes sense. I shouldn't need publishing in routing mode in the first place, unless I want to point to the security server IP and forward it internally, but I could just create an access rule and dnat it from the external firewall to the internal one. This works as well. Something nice to point out, if you just change the setting to NAT and then change it back to routing, so one would assume nothing has changed, rerunning the change security level wizard is not possible. Apparently upon changing nat/routing mode it changes some other things and the wizard can not handle this. It will advise to reset the rule set to default. Need some advise now as I'm not really familiar with ISA/TMG. The customer here wants to exclude some users from internet. Our external firewall can only do this on IP basis, unfortunately we can't do it that simple here as users roam across workstations, so some form of authentication is required. I do NOT like double NAT. In fact I hate it . It makes logs in myexternal firewall nearly useless as everything passing it appears to come from the security server. And I've seen in the past that some applications don't work (well) with double NAT, although theory states it should not be an issue. As I must run the ISA/TMG, it might as well do something. So I figured I'd take the easy route, set the security level to medium-high, ISA/TMG will then filter etc. and just turn off the NAT and voila. This doesn't work thus. Setting the security level to low allows SMTP on the external interface, as it drops NAT. All rules except the first one are made useless as the first rule states: From anywhere, to anywhere, any protocol, accept. This will obviously remove any firewalling on the external interface and thus opens 25. The publishing rule which remains further down doesn't do anything any more. It still uses proxy for caching, but that's about it. All other features are disabled. No authentication, no packet filtering, no virusscanning, nothing but webcaching according to the manual. I'm thinking about doing the following now: Setting security level to medium-high. Changing to route mode. Remove the default SMTP publishing rule. Create an access (not publishing thus) rule for SMTP to the security server. Go past other rules and see what I can trash. Add a rule to allow all traffic out (for authenticated users and some static IPs). Whilst TMG isn't my favorite firewall, not using any of it's features if I must run it would be a shame. It might as well provide an additional level of defense and be used to block internet for users that aren't allowed (still have to figure out how to do this, but other issues now first.. like the rest of the migration ).Would this be a setup you'd recommend, or am I better of with security level low and adding all the features myself? Does anyone predict any problems with proposed setup? There are several rules in the TMG that seem to act like a reverse proxy rewriting URLs. Mainly the rules allowing access to the OWA, RWW, companyweb etc. Not sure what these will do. TIA On 30-12-09 14:28, Freaky wrote: > Finally got the change ip wizard to change the IP's, so they are finally > set up properly. Or well... somewhat properly. > > Now we run into the strange issue that the security server registers > it's external, not it's internal, IP in the DNS. Which makes me think > the interfaces were swapped at some point. This might also explain why > the SMTP rule points to the internal IP. It might just consider it the > external interface on some weird point. > > Now I can't run the change ip wizard anymore. It claims I'm either not > administrator, or that it has no connectivity to the domain. I can > access fileshares etc. just fine though. Can also connect with computer > management to other servers etc. > > > On 30-12-09 12:00, Freaky wrote: >> Trying to track this at a lower level. >> >> Apparently during the original installation my collegues setup internal >> as 10.1.1.254/24 and external as 10.10.1.254/16. The subnets are >> actually reversed on this and they changed these manually (ie without >> the wizards). >> >> I'm guessing the rule generation wizard (or whatever it's called )>> pretty much borks out on this change. >> >> Trying to re-set the IP addresses with the change ip address tool, but >> this isn't working as the wizard has some dumb requirement on me >> entering a gateway on the internal interface for the security server. >> The security server obviously only has a gateway on the external >> interface and the wizard refuses to reconfigure without entering the >> gateway. >> >> So far no solution on that. >> >> They also changed the password for the administrator, but it seems this >> only has causes issues with monitoring, which should be resolved now. >> >> Think the best way to proceed now is to somehow get the wizard to change >> the ip addresses to the proper ones, reset the firewall rules back to >> default (i hope by default it means recreating them, not importing a >> backup from installation time...) and fixes edge stuff etc. >> >> Found some docs in which the edge server uses the external DNS servers >> for routing to the outside world, but this currently isn't possible >> either as with the default firewall rules the security server itself is >> not allowed to connect to DNS servers on the internet. Only DC's are >> allowed, atleast with the security level set to medium-high. Whether or >> not this is because rules aren't generated properly or if it's a mistake >> in the rules creation is yet to be seen. >> >> The IP isn't really reachable from the outside, you need to publish >> firewall rules for it. That it is wrong is quite obvious however, it >> should just publish the external IP. The funny thing is that it allows >> from anywhere, from interface external to the IP on the internal side... >> I would have just chosen the IP on the external side as 25/tcp is bound >> to all according to netstat anyways (0.0.0.0:25 is listening). This is >> the default rule created by the management server (I have 'reset' the >> rules to default however through the EBS console and as mentioned I'm >> not sure whether it recreates them based on info it has on IP >> settings/network layout or if it just imports the rule set it created on >> installation). >> >> Unfortunately this is our only EBS installation so I can't check how it >> creates the SMTP publish rule on a normal operating EBS setup. If you >> could check on your side that would be awesome .>> >> The rule settings: >> >> Name: Allow incoming email by publishing SMTP Mail Server >> Enabled / Allow / Log requests matching this rule >> Protocol: SMTP Server >> From: Anywhere >> To: 10.1.1.254 (internal IP Security/Edge Server) >> Requests appear to come from original client (luckily it got this right >> otherwise we'd probably be open relay )>> Networks: External >> Schedule: Always >> >> Thanks for the re' >> >> On 30-12-09 10:38, Cliff Galiher wrote: >>> Even with NAT disabled, my point is that a NIC gets an IP bound to it as >>> part of the windows networking stack initialization. Even with a rule >>> published in TMG, that IP should not be directly accessible externally. >>> You may not agree with me on that point, but considering you obviously >>> *have* problems with traffic getting to and from your security server, >>> you may not want to dismiss my assessment *quite* so quickly. That is, >>> of course, ultimately your decision to make however. >>> >>> -Cliff >>> >>> >>> "Freaky" <> wrote in message >>> news:... >>>> No, not really. I have turned of NAT and set it to routing. The >>>> Fortigate knows the route oc and there is a publish rule in TMG that >>>> exposes it. Without the TMG publish rule internal is not reachable. >>>> >>>> All e-mail is stuck in the queue under 'submission'. Normally, when >>>> routing to external, it creates queues for the domainname. >>>> >>>> Thanks for the re'. >>>> >>>> >>>> >>>> On 29-12-09 19:47, Cliff Galiher wrote: >>>>> Just the fact that you can forward traffic to 10.1.1.254 is a sign that >>>>> you have a physical network problem. The NIC with that IP should not be >>>>> directly reachable from the fortigate, so the fact that the fortigate is >>>>> reaching it shows an exposed internal NIC on the external network. >>>>> >>>>> -Cliff >>>>> >>>>> >>>>> "Freaky" <> wrote in message >>>>> news:#L#... >>>>>> Hi there, >>>>>> >>>>>> whilst I was on vacation my collegues installed our first 2008 EBS >>>>>> server(s) at our office location. Whilst doing this they used the DNS >>>>>> servers for our ISP, as well as probably some other settings they >>>>>> had to >>>>>> change to make it fit the network here. >>>>>> >>>>>> Currently the network layout is as follows: >>>>>> >>>>>> >>>>>> Internet <ext ip> FortiGate Firewall <10.10.1.1> <-> <10.10.1.254> TMG >>>>>> Server <10.1.1.254> <-> LAN (10.1.x.x/16). >>>>>> >>>>>> By now I finally got the outgoing e-mail working. Several things I find >>>>>> *extremely* peculiar. >>>>>> >>>>>> I have reset all the firewalls rules back to default on the TMG server, >>>>>> enabling everything as it was. As there is an internal subnet between >>>>>> the external gateway and the TMG I have changed TMG to do routing (and >>>>>> thus not NAT) on the external IP. Changed the security level to >>>>>> medium-high and added a rule to allow all traffic out (otherwise only >>>>>> HTTP/HTTPS gets out from clients). >>>>>> >>>>>> First thing I noticed is that in the default rules SMTP is published, >>>>>> but this is not reachable on the external IP of the TMG (10.10.1.254). >>>>>> Telnetting to 10.10.1.254 25 from the fortigate (from 10.10.1.1 thus) >>>>>> results in no connection. Forwarding 25 from the external IP on the >>>>>> fortigate to the 10.10.1.254 IP (external TMG) results again in no >>>>>> connection. This I find very peculiar, as if there was no additional >>>>>> firewall the 10.10.1.254 should be considered external and thus SMTP >>>>>> traffic should work on it, otherwise one can not receive email at all. >>>>>> >>>>>> Forwarding to 10.1.1.254 works though. Which I find very peculiar (I >>>>>> did >>>>>> add a route on the fortigate that 10.1.0.0/16 is behind 10.10.1.254 oc) >>>>>> and scary as it's forwarding to an internal IP behind another firewall >>>>>> and that firewall should be routing/accepting or nat'ing/forwarding it, >>>>>> and I think something is seriously borked because of this. >>>>>> >>>>>> Mail now enters the queue on the TMG/Edge Transport. There the first >>>>>> thing I see in message tracking is it entering from external client IP >>>>>> to 10.1.1.254. And after that things start to get really strange. >>>>>> >>>>>> I see the same e-mail message tens of times after that, only now it >>>>>> comes from the internal IP of the fortigate (10.10.1.1) going to >>>>>> 10.1.1.254 (internal TMG) (I think it is source NAT'ed because the >>>>>> source was internal and then going to external IP (because of DNS >>>>>> lookup >>>>>> resulting in MX records pointing at external IP) and because then after >>>>>> port forward it would look like 10.1.1.254 -> 10.1.1.254 it is source >>>>>> nat'ed by the fortigate to keep it working). After that it will show up >>>>>> as going from 10.10.1.254 (external TMG) going to x.y.200.1 (where our >>>>>> external IP is x.y.200.125/29, so not in our subnet but definitely >>>>>> close). I don't know what the modem uses as gateway, our gateway is >>>>>> x.y.200.126 (which is the modem thus) and I am guessing it's the >>>>>> gateway >>>>>> behind the modem. >>>>>> >>>>>> These 2 lines repeat over and over. There is no mailserver on the >>>>>> x.y.200.1, there is no smarthost configured either (all mail should be >>>>>> routed through DNS), so why it hits that IP is beyond me. I don't find >>>>>> the tracking center very informative. In 2003 one could see states, >>>>>> etc, >>>>>> all you see now are some ID's, IP's and that's about it. Can I see >>>>>> more? >>>>>> >>>>>> It seems that although the edge server recognizes the domains for >>>>>> incoming as accepted locally, it doesn't know how to route them to the >>>>>> exchange server. What's also strange is that recipient filtering is on, >>>>>> it still accepts which it then >>>>>> obviously would need to bounce afterwards. >>>>>> >>>>>> Earlier I didn't get any mail out either. It all got stuck in the >>>>>> outgoing queue with a 451 DNS lookup failure. Removed the DNS servers >>>>>> (externally) that were entered in the external interface. Besides the >>>>>> fact they aren't from the ISP the customer uses (and thus won't >>>>>> respond) >>>>>> the default TMG settings actually do *not* allow the TMG server to >>>>>> access DNS on the internet. So I'm just using the internal DC's DNS >>>>>> servers now which is fine. Still didn't work as the Edge Transport was >>>>>> still trying to use DNS servers from the external interface, which were >>>>>> none.... So set them manually in the edge transport config. Outgoing >>>>>> mail is fine now. >>>>>> >>>>>> On 2003 SBS one would probably easily solve this by running the >>>>>> internet >>>>>> and e-mail wizard again, but I see nothing of the likes. >>>>>> >>>>>> I'm somewhat reluctant to continue troubleshooting with my default >>>>>> methods as these are non-EBS/SBS oriented. With 2003 this frequently >>>>>> resulted in the very fine wizards biting us in the ass when they were >>>>>> ran again and so I'd like to do this as much through the official EBS >>>>>> wizards/toolies as possible. >>>>>> >>>>>> Any help is greatly appreciated. >>>>>> >>>>>> TIA >>>>> >>>> >> > |
|
|
|
|
|||
|
|
| |
|
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| I also have an error 646 in Windows update. Please help. | Jose | Windows Update | 12 | 01-09-2010 02:00 PM |
| Re: Newbie with issues concerning WSUS, clients, GPOs and SBS 2008 | Cliff Galiher | Windows Small Business Server | 0 | 12-19-2009 08:43 PM |
| Duplicate Emails | Rick | Windows Live Mail | 12 | 12-07-2009 09:17 PM |
| Running DOS Games under Vista | Wogerwabby | Windows Vista Games | 45 | 11-10-2009 04:33 AM |
| Using Storage Folders Instead of Default Folders | Peter Dryton | Windows Live Mail | 9 | 10-26-2009 01:21 PM |
Linear Mode
