>> This will allow to verify the your daytime client is really talking to the
>> ports you think it is.
>thanks, but this rule do not produce any log
This confirms what I expected - that your original ruleset did not make
sense based on my knowledge of daytime servers. Typically, you would not
be running an daytime server on your system, but rather you would be
running at daytime client. The client would connect to port 13 on the
external daytime server.
This might get you some packets traced
Daytime_out_log
Rule-Action = Log,
Comment = "Packet received from 192.168.1.10:13",
Source = "192.168.1.10",
Destination-Port = "13",
Log-Control = Enabled,
Log-Mask = "date time severity message resolved_source resolved_dest",
Log-File = "daytime_out.log"
>> BTW, what daytime client are you trying to use?
>i don't recall exactly,
You really ought get that problem fixed.
but it works perfectly if i use mlink on the VM1
>VM1 has 2 Nics
>maybe Injoy FW can't do what mlink does?
That's possible, but it still could be your rule set.
>>> This is the mlink rule:
>>> link daytime 0.0.0.0:13 193.204.114.105:13
>>> access daytime 192.168.1.10
Having never used mlink, my read of this rule is that any attempt to
connect via port 13 will be sent to port 13 at 193.204.114.105 as long as
the attempt originates from an interface bound to 192.168.1.10.
I would not call this port forwarding. It's more link NAT to my way of
thinking.
tilbake listen