The safe thing is to assume that you always need to specify a metric when you redistribute into EIGRP. There are a few exceptions, such as redistributing something that EIGRP considers to be connected. But it is easier to always supply a default metric than it is to figure out what are the few exceptions.
The metrics would not necessarily differ between LAN and WAN. If you want to come up with an approach that makes the default metric worse for WAN and for LAN (and to manage the redistribution to apply the correct metric - probably requires a route map to control the redistribution and to apply different default metrics) then you could do that. But I would not consider it worth the effort that it will require.
Here is part of what I think about the metrics used for redistribution: our IGP routing protocols use metrics to compare paths toward the destination and to choose the best path. That works pretty well as long as the metrics do accurately reflect what it takes to go down that path - and we generally trust the metrics for destinations learned within the routing protocol. But when we redistribute we are making up a metric. The metric that we supply in redistribution is not particularly accurate in describing how attractive (or unattractive) this path really is. My approach is to use a metric that suggests that the destination is reachable through this path but it is not particularly attractive. And for me it is not worth it to try to distinguish in the metric supplied whether the path is based on LAN or on WAN. If the routing protocol is comparing two paths where one has a metric learned within the routing protocol and we know it is accurate and the other path has a default metric I would rather use the path where I know the metric is accurate than the path which is a guess.
I hope that perspective may help you a bit.
HTH
Rick
HTH
Rick
