New Member

Question

Cannot access internal lan2 from internal lan1

Forum|Forum|14 years ago
January 28, 2012
13 replies
10292 views

I have the 60c all setup and everything almost works as I want it to. 1st issue - I created a rule to be able to access LAN2 from LAN 1, both being on different subnets with the LAN ports operating in -- mode. I use LAN 1 for all traffic except my VoIP LAN, LAN2. The rule is simple and didn' t require a route policy. It worked fine until I upgraded form 4.0 MR2 to MR3 patch 4 The rule is as follows: Source Interface /Zone: Internal 1 Source Address: 192.168.103 range (Created an address 192.168.103.0/24) Destination Interface /Zone: Internal 2 Destination address:192.168.106 Range (Created an address 192.168.106.0/24) Schedule: always Service: Any Enable Nat: no It worked before the upgrade - now I can only access the Interface address of 192.168.106.1. Logs show " started" under status when I try to access anything else other than the port itself. All I want to do is be able to use HTTP to access the VoIP Lan/phones etc... Makes no difference where I put the rule, it still doesn' t work. I tried adding a Policy Route, but that didn' t change anything. I know this should be an easy fix...but I' m stumped. I also have a few VPN tunnels at the top of the list, and they work perfectly On another note - I' m on a MAC in a Windows Domain...and since moving away from my Sonicwall' s...the network browsing is ungodly slow on the MAC' s. Spoke to T/S and they tried and tried but were not able to resolve that issue.

ede_pfau

SuperUser

Hi, and welcome to the forums. You' re right, this should be simple. Unfortunately, you' ve left out relevant parts of the config which I kindly ask you to provide: - the interface config for int1 and int2

conf sys interface    edit internal1  ...

- the routing table as it' s running

get router info routing-table all

I suspect the interface definition as the culprit, but let' s see.

Steve_WertheimerAuthor

New Member

Thank you for your response - Here' s the Router Table running and the interface config...as well as the configuration of Internal 1 Internal 2 is the same - only on the 2nd internal subnet... Connected S* 0.0.0.0/0 [5/0] via 206.248.154.104, ppp1 [5/0] via 69.165.xxx.xx, wan2 C 69.165.xxx.xx/28 is directly connected, wan2 C 69.196.xxx.xxx/32 is directly connected, ppp1 C 192.168.103.0/24 is directly connected, internal1 C 192.168.106.0/24 is directly connected, internal2 C 206.248.xxx.xxx/32 is directly connected, ppp1

Qo40603.jpg

ede_pfau

SuperUser

CLI is leaner... a) check the address object for LAN2 of course, if it worked before the upgrade then it should work now... b) update to the latest patch level, 4.0MR2patch10 Download the config file first.

Steve_WertheimerAuthor

New Member

Sorry - I meant MR3 patch 4...just edited the post. Address object is fine and is used in other rules...so no problem there. I' m stumped....

FortiRack_Eric

New Member

find out why traffic is not going thru firewall diag debug enable diag deb flow filter src x.x.x.x diag deb flow filter dport or proto 1 (for ICMP) diag deb flow show console enable diag deb flow show funct enable dia deb flow trace start 10 (trace 10 packets) and give output here good luck

Steve_WertheimerAuthor

New Member

I started the debug in the CLI - but it gives me a parse error before " src" when trying to enter " diag deb flow filter src 192.168.103.170" . I don' t have any experience with the CLI - so it may be me, but I followed your instructions to the letter and it' s not allowing me to proceed further.

ede_pfau

SuperUser

it' s " saddr" , not " src" . Just type a " ?" if you don' t know the exact syntax at that point of your input.

Delta

New Member

Does it work if you change the destination address in the policy from your specified range to all? You' ve listed the address as the same as your source address ... not sure if that' s a typo ...

Steve_WertheimerAuthor

New Member

I ended up installing a policy route that looks like this and it now works perfectly - it would not work without a policy route - If incoming traffic matches: Protocol 0 Incoming interface: Internal1 (Non-VoIP LAN) Source address / mask: 192.168.103.0/255.255.255.0 Destination address / mask: 192.168.106.0/255.255.255.0 Force traffic to: Outgoing interface: internal2 (VoIP LAN) Gateway Address: 0.0.0.0 Thanks to everyone who offered their suggestions! Problem is resolved 100%!

FortiRack_Eric

New Member

If you have to use policy route then your routing was wrong in the first place. You better take a good look on your active routing table. The diag debug flow would have shown that the routing choice would not have matched internal2 as a destination interface. You will run into other problems that have to be fixed with another policy based routing and so on. This is a wrong fix.

Steve_WertheimerAuthor

New Member

When I spoke to the Fortinet tech' s, they told me the rule would not work without this policy and that this was the correct way to do it. Now, I' m confused...

ede_pfau

SuperUser

I agree with Eric. You don' t have to set explicit routes or even policy routes to achieve this, as both networks are directly connected (see routing monitor in one of your earlier posts). Is there anything related that you haven' t mentioned?

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO