Port forwarding to DMZ (SOLVED)

[#1]

I am pulling my hair out. Firmware Version: Fortigate-60 2.80,build519,060809 I am trying to set up port forwarding from WAN1 to the DMZ to route email traffic. I am also setting it up for ssh at the moment, mostly to do testing. Configuration:

 Virtual IP:
 Name 			IP	 	Service Port 	Map to IP 	Map to Port
 Scheidegg_DMZ_SMTP 	wan1/0.0.0.0 	tcp/25 		10.10.10.2 	tcp/25
 Scheidegg_DMZ_SSH 	wan1/0.0.0.0 	tcp/2224 	10.10.10.2 	tcp/22
 
 Firewall policies:
 WAN1 -> DMZ (2)
 ID 	Source 	Dest 			Schedule 	Service 	Action 	Enable
 8 	all 	Scheidegg_DMZ_SSH 	always 		SSH 		ACCEPT
 10 	all 	Scheidegg_DMZ_SMTP 	always 		SMTP 		ACCEPT
 

I have verified that when I actually am in the DMZ, I can access the machine on the ports requested (25 and 22). But from the outside (WAN1), packets don' t go through. I have other port forwardings defined from WAN1 to Internal, and they work as expected. I remember I went through some trouble configuring VPN at the time. I still don' t understand why the VPN policy is " inverted" (from internal to WAN1 and not the reverse). Is there some similar weird trick to do with DMZ? Or maybe I am just missing something so obvious? Thanks, Laurent

[rwpatterson]

Have you tried replacing the wildcard in the virtual IP definition with the interface IP address (or the virtual IP address on the network)?

[#3]

Thank you for your reply. Yes, I have tried. No dice. Again, the weird thing is that if I recreate the same policies but going to the internal network (with proper mapping of the VIP addresses), it works fine. Of course, this defeats the whole purpose of having a DMZ. I am able to do this since the machine in question has two NICs, one on the internal network, one on the DMZ. I have wired both of them for testing.

[Fireshield]

The process is the same for VIPs to either the internal or the dmz, and what you have here looks correct. As Bob suggested earlier, I would recommend using an actual public IP rather than the wildcard. I' ve seen wildcards do odd things before and therefore avoid them when at all possible. Some of the things to check - have you sniffed the traffic to see what' s happening with it? Is it getting through the firewall and something else is giving issue?

[#5]

Do you have multiple IP' s ? Replace the 0.0.0.0 with the right external IP address. Secondly is the segment of your DMZ really 10.10.10.x/24? Perhaps obvious, but still. Finally, I trust that you have not been messing with routing trying to solve this. Regards, Eric

[#6]

Following your suggestions: - No, I haven' t touched the routing tables. - I have changed the address to use the WAN' s public address. - Yes, the interface and the DMZ are configured with the network 10.10.10.0/255.255.255.0 - I did however run tcpdump to see the traffic and noticed that ... traffic is going through, but the interface is somehow not replying. Here is the result:

 # tcpdump -i eth1 port 22
 [snip]
 15:13:21.880934 IP dXXX-XXX-XXX-XX.XXX.XXX.XX.29897 > YYYYY.ZZZ.ssh: S 4222539634:4222539634(0) win 65535 <mss 1400,nop,nop,sackOK>
 15:13:24.745424 IP XXX-XXX-XXX-XX.XXX.XXX.XX.29897 > YYYYY.ZZZ.ssh: S 4222539634:4222539634(0) win 65535 <mss 1400,nop,nop,sackOK>
 ... repeats until time out
 

It' s weird, because the interface responds fine when I plug my laptop directly into the DMZ and connect via ssh. So what is different when going through the Fortigate' s firewall policy?? For a second I thought I had to setup a reverse policy for outgoing traffic, but there' s actually one already to let all outgoing traffic pass. I just don' t get it. Laurent

[rwpatterson]

Are you testing the connections from a second PC? If you are trying with the twin NIC machine, I believe you may have issues. Trying out the external-DMZ policy when you' re connected to the DMZ directly won' t work.

[#8]

Ok, I figured it out. It was a stupid routing problem between the two NICs on the server. eth0: 192.168.1.2/255.255.255.0 gw 192.168.1.1 eth1: 10.10.10.2/255.255.255.0 So, I could connect to it fine in the " internal" network, via interface eth0. Connection on the " DMZ" interface eth1 from inside the DMZ worked because there was no need to do routing (within the subnet). But when I was coming in from the outside into the DMZ, packets were coming in to eth1, BUT RETURNING via the default gateway on eth0, and probably getting dropped quickly. And I thought I would simplify my life by setting up the second interface to do easier testing... Thank you all for your assistance and suggestions. I do hope this will help someone else. Laurent